Archivo de la categoría: Sin categoría

Blog WordPress con usuarios de AAD

En este artículo vamos a explicar la manera mediante la que se puede crear un blog WordPress como en el que nos encontramos, alojarlo en Azure y acceder como usuario al mismo utilizando los usuarios de un tenant de nuestra suscripción de Azure.

Creación del sitio

En primer lugar debemos de crear el sitio web, para ello en el portal de Azure, pulsaremos sobre “nuevo” y buscaremos WordPress, podemos seleccionar la opción por defecto o WordPress sobre Linux. Cuando tengamos seleccionado la aplicación wordpress le daremos un nombre y crearemos un plan de aplicaciones y una base de datos.

 

Cuando el sitio web se haya desplegado accederemos al sitio web para comenzar la configuración inicial de wordpress en la que seleccionaremos el idioma, un título para el sitio y nombre y contraseña de usuario administrador, dicho usuario nos servirá para las configuraciones iniciales del sitio, al final de la configuración lo eliminaremos.

Para utilizar Single Single On en WordPress con los usuarios de nuestro tenant debemos descargarnos un plugin desde https://github.com/psignoret/aad-sso-wordpress, una vez lo tengamos descargado lo instalaremos desde la pestaña de “Plugins” desde la consola de administración del sitio wordpress.

Creación de la aplicación en el tenant

A continuación, crearemos la aplicación en nuestro AAD para que WordPress pueda utilizar a los usuarios de nuestro tentant, para ello nos dirigiremos al portal clásico, Azure Active Directory, aplicaciones, crear nueva,aplicación que mi organización está desarrollando. Cuando se nos pregunten las direcciones del sitio, para el url de inicio de sesión añadiremos /wp-login.php a la dirección del sitio.

 

 

Cuando la aplicación esté creada debemos dirigirnos a “configuración”, desde ahí crearemos una nueva clave para la aplicación la cual habrá que cambiar cuando expire (Cuando guardemos los cambios se nos mostrará dicha clave) Y en permisos delgados marcaremos “Read Directory Data” y “sign in and read user profile”

 

 

Guardaremos y esperaremos a que sen muestre la clave de la aplicación la cual copiaremos debido a que no se volverá a mostrar por seguridad.

 

Habilitación de Single Sign On 

Cuando dispongamos de la clave, volveremos al sitio wordpress y nos iremos a la configuración del plugin, en dicha pestaña, introduciremos la clave de la aplicación creada, el client secret que se nos muestra también en la aplicación creada en el tenant y marcaremos la opción “Enable Auto-Provisioning”  para que se creen los usuarios automáticamente. Una vez realizada esta operación, ya podemos acceder con un usuario de nuestro tenant al sitio web, sólo nos queda un último paso, hacer a un usuario de nuestro tenant administrador, eliminar al administrador local e impedir que se pueda acceder al sitio mediante usuarios locales. Para ello, desde la web de inicio de sesión, pulsaremos en Sing in with your “app” account lo que nos redirigirá a un ADFS de micorsoft en el que iniciaremos sesión con nuestro usuario del tenant.

 

 

Una vez hayamos iniciado sesión con el usuario, podremos darle permisos de administrador con la cuenta local de administrador desde el panel de administrador de WordPress “usuarios”.

Finalmente con el usuario del tenant, accederemos al mismo panel de usuarios y eliminaremos al usuario administrador local y, en la pestaña del Ajustes, Azure AD marcaremos la opción “Enable auto-forward to Azure AD” para que cuando un usuario acceda a la página de inicio de sesión se vea automáticamente redirigido al ADFS.

Conclusiones

En apenas diez minutos podemos crear un sitio web WordPress y utilizar los usuarios de un tenant para que puedan acceder a dicho sitio web, de tal manera nos ahorraremos tener que crear usuarios en el sitio web.

 

 

 

Proceso de sincronización. Resolviendo InvalidSoftMatch en ADConnect

El objetivo que me he planteado para este artículo, es explicar a alto nivel el proceso de sincronización, y, una vez establecido el contexto, ver algunos de los errores que podríamos tener, en concreto el tipificado como InvalidSoftMatch. Pero antes de entrar en materia, me gustaría poner un poco de contexto.

¿Qué es ADConnect?

ADConnect es un elemento fundamental en implementaciones de identidad sincronizada o federada con Azure AD (AAD). Nos sirve para poder emplear las credenciales de nuestro directorio local, en servicios proporcionados por Azure AD, y, así, tener una mayor experiencia de integración.

En el core de las aplicaciones que instala, se encuentra el servicio de sincronización. Sin entrar en mucho detalle, esta herramienta, mediante el empleo de ciclos de sincronización regulares, divididos en distintas etapas (Import, Sync y Export), va a realizar una “comparativa” de los elementos que hay en local, con los de Azure, y, realizará las acciones necesarias: creación, actualización, eliminación. Esta “comparativa” la hace empleando los parámetros configurados durante la instalación de ADConnect.

¿Cómo funciona la sincronización?

El proceso de sincronización, permite  establecer una correspondencia entre los elementos que existen en local y los de Azure.  Son necesarios 2 atributos del directorio local para ello :  un atributo para el inicio de sesión, y otro, para identificarlo de forma única o ImmutableId (que permanecerá inalterable a lo largo de la vida del objeto). Los valores empleados  por defecto (aunque no los únicos), son respectivamente el UserPrincipalName y el ObjectGuid.

Durante la sincronización, los objetos son importados , convertidos a un formato  apropiado, y por último provisionados o actualizados en el destino (si hubiera modificaciones).  El objectGUID del usuario de origen es convertido a base 64 y pasará a ser el atributo ImmutableId en AzureAD.

Errores de sincronización

Si bien, en un entorno perfectamente controlado los errores de sincronización no suelen ser frecuentes, puede darse situaciones, en las que nuestro ADConnect reporte algún error al realizar alguna exportación.  Éstos podrán visualizarse en la pantalla de operaciones del administrador de sincronización, y para poder analizarlos y solventarlos, tendremos que acceder a cada uno de ellos.

Entre los errores que podemos encontrar figuran: ObjectTypeMismatch, AttributeMustBeUnique, InvalidSoftMach entre otros. Nos centraremos en el error InvalidSoftMatch.

Error InvalidSoftMatch

Este error aparece porque hay una incoherencia en el atributo ImmutableId. Si un usuario está correctamente sincronizado su UserPrincipalName y su inmutableId (en AD y AAD) deben ser el mismo. En este caso, el UserprincipalName coincide, pero no el ImmutableId, y,  por tanto, no se puede realizar una correspondencia con ese usuario. Este error puede producirse cuando un objecto de ADD ya está sincronizado, y, en el directorio de origen se elimina ese objeto y se crea otro con las mismas propiedades.  Al crear un nuevo objecto, se generará un nuevo GUID, que no coincidirá con el de AAD.

Para poder solucionar este error, debemos hacer un “Hard Match” o macheo manual, que consiste en cambiar el ImmutableId del  usuario de AAD, por el correcto del directorio local.  Previamente nos tenemos que conectar a O365 con usuario administrador global del tenant.

Como último comentario, indicar,  que si nuestro dominio está federado, necesitaremos previamente cambiar el UPN por el de un dominio no federado para machearlo, y a continuación establecer el upn correcto.

¡Hasta el próximo post! 🙂

 

Azure AD Privileged Identity Management

Dentro de la suite de seguridad que nos proporciona Azure EMS, encontramos la solución ante una de las dudas que muchos usuarios y administradores del servicio han tenido.

¿Cómo concederíamos acceso administrador o de servicio a nuestro tenant de Office 365 o Azure Active Directory durante un tiempo limitado o mediante revisiones teniendo un registro de auditoría de todo el proceso?

La solución a ese problema se denomina: Azure AD Privileged Identity Management.

En primer lugar, para realizar un deployment de la aplicación en nuestro servicio de Azure AD, son necesarios los siguientes requisitos:

  • Acceso administrador global.
  • Licencia Azure Active Directory Premium Plan 2, la cual podemos activarla de forma independiente o a través del paquete de Azure EMS E5.

Caso de uso

Procedemos a su búsqueda en el portal de Azure y activación. Al realizar el primer acceso, automáticamente aparecerá el Security Wizard, el cual nos guiará para activar los administradores de PIM (Privileged Identity Management), revisar el acceso permanente para los administradores de los diferentes servicios como actualmente o cambiarlos a elegibles, en caso de optar por ésta segunda opción, su administración se realizará a través de diferentes peticiones y con un tiempo limitado.

Una vez que tenemos todo configurado, veremos lo siguiente en nuestro portal:

Vamos a explicar cada uno de las opciones por pasos:

  • Activate my roles: En caso de ser un administrador elegible, podremos activar los roles de administrador al servicio que nos hayan proporcionado indicando la razón de esta necesidad y por defecto, es obligatorio hacer uso de MFA para que los roles puedan ser activados.

Una vez activado, podremos observar la fecha de espiración del rol asignado:

  • Managed privileged roles: Desde esta sección podremos ver un resumen de los diferentes roles de administración que tenemos asignados en nuestro directorio, así como alertas en caso de que los valores en las políticas que hayamos definido se hayan superado, un resumen de auditoría y las diferentes opciones presentes para modificar las políticas que debe de cumplir cada rol.

Desde el historial de auditoría podremos ver el número de activaciones de roles que se ha producido durante el día, así como diferenciar por colores los diferentes roles que tenemos activos en nuestro directorio, pudiendo exportar en todo momento esta auditoría a un fichero .csv para analizar los datos mejor en nuestro cliente preferido:

Desde el apartado de configuración, podremos modificar las políticas de acceso a un determinado rol, en este caso seleccionaremos el de administrador global desde el cual podremos indicar el número de horas que vamos a permitir de acceso (mínimo 30 mins.), enviar emails de las activaciones que se producen por los administradores elegibles a los administradores actuales del directorio, requerir un número de ticket para el usuario que quiere escalar sus privilegios en el directorio y por último y de manera obligatoria, requerir MFA.

En las configuraciones de alertas podremos definir por ejemplo, el trigger con el cual queremos que nos alerte de que nuestro directorio cuenta con > X administradores, etc.

Por último, en las configuraciones de revisiones de acceso podremos definir, notificaciones de emails, recordatorios, requerir una razón para aprobar o denegar el acceso y la duración en días que una revisión de acceso estará disponible.

  • Review privileged access: Desde este último punto, podremos revisar los roles que tenemos pendientes de los usuarios elegibles en caso de que así lo hayamos configurado previamente, podremos seleccionar quién o quiénes serán los revisores y deberemos de aprobar o denegar el acceso de esos administradores elegibles con una razón, por defecto nos enviará emails recordatorios y hemos marcando un tiempo máximo de 30 días.

Conclusiones

Viendo la versatilidad del producto, es importante tenerlo en cuenta para aumentar la seguridad en nuestro directorio activo de Azure, alertarnos de diferentes aspectos de administración e incluso establecer políticas de revisiones de acceso para escalar un rol determinado en nuestro entorno.

Esperemos que os haya gustado el ejemplo de uso en un entorno real.

Azure Service Bus Topics

Otro servicio que ofrece el Service Bus de Azure, junto con las ‘Queues’, ‘Relays’ e ‘Event Hub’ son los ‘Topics’. A diferencia de las queues, donde sólo hay un receptor, en los topics puede haber múltiples. Esto es así debido al sistema que emplea basado en suscripciones, en el cual un topic  puede tener registradas múltiples suscripciones, estando cada una asociada a un receptor. Dicho receptor solo recibirá los mensajes que hayan sido previamente filtrados por la propia suscripción, lo que permite controlar la información que llega a cada receptor atendiendo, por ejemplo, al perfil del mismo.

Instalación

El proceso de instalación o creación es el mismo que el de una Azure Service Bus Queue. Unicamente tener en cuenta que ‘Messaging Tier’ debe estar establecido como mínimo en ‘Standard’, a diferencia de las queues.
La cadena de conexión se recupera de manera análoga.

Funcionamiento

El funcionamiento es muy similar al visto para las ‘queues’, con lo que todo lo comentado para estas se aplican aquí. De esta manera, este servicio es susceptible de ser empleado con diferentes lenguajes (Java, Node.js, .NET, PHP, Ruby o Python). Para los ejemplos se empleará Python.
La gestión de los topics, así como de las suscripciones pueden hacerse asimismo desde el propio portal.

Un código de ejemplo con las operaciones básicas sería el siguiente:

Conclusiones

Como se ha visto, el funcionamiento es muy similar a las colas de Services Bus, con la diferencia fundamental del número de receptores del mensaje. Esta característica, unida a la posibilidad de establecer filtros en cada suscripción, permite un grado de versatilidad con que la anterior estructura de datos no contaba.

Herramientas Útiles

Me gustaría hablar de dos herramientas muy útiles en el día a día, que pese a su sencillez no por ello dejan de ser útiles.
Una de ellas de un emulador de terminal llamado cmder. Si bien Carlos habló en este post de otro llamado ConEmu, esta otra alternativa también resulta bastante interesante.
La otra herramienta se llama PingInfoView, y su cometido es el de realizar un ping a las máquinas que establezcamos, con lo cual se sabrá en todo momento si éstas están en línea o no.

cmder

Como se ha dicho, el cmder es un emulador de consola, lo que significa que actúa a modo de intermediario con el intérprete. Esto vendría a decir que se puede personalizar y adecuar más a las necesidades y gustos del usuario (siempre dentro de un límite). La configuración es bastante completa, permitiendo alterar diversos aspectos, desde el grado de opacidad, el tipo de fuente a emplear, pasando por la integración de diversas aplicaciones en las múltiples pestañas que se pueden desplegar, etc.
Sin duda, el grado de configruación es lo que le confiere potencia y versatilidad a este emulador de consola, si bien al principio puede resultar algo engorroso debido a la cantidad de opciones.

2016-06-19 20_34_57-Cmder

PingInfoView

Esta aplicación nos permite realizar ping a una serie de máquinas establecidas en una lista a introducir de forma manual o bien desde un archivo externo. El programa permite establecer alarmas visuales y sonoras en el caso de fallos, así como exportar informes en HTML, establecer la frecuencia de los pings, etc.

2016-06-19 20_32_00-PingInfoView

Un programa sencillo pero que cumple su cometido a la perfección.

Azure Service Bus Queues

Qué es

El Azure Service Bus Queues (ASBQ), al igual que el servicio Azure Queue Storage (se habló de el en este post) hace uso de una estructura de datos basada en cola para el envío de mensajes. A diferencia de este último, el ASBQ no requiere de una Storage Account para su funcionamiento.

Instalación

La instalación es bastante directa y sencilla. Hay que llevarla a cabo desde el portal clásico (ya que desde el portal nuevo, nos redirigirá al primero).

De este modo, en el portal clásico, hay que situarse en “Service Bus” y pinchar en “Create”. Hecho esto, aparecerá una pantalla donde se indicarán los datos del servicio.

Creando ASB 1

Se dará un namespace, el tipo será ‘messaging’, se elegirá el nivel acorde a las necesidades, así como la región (el rendimiento será mejor cuanto más cerca). Una vez creado el servicio, aparecerá en el panel.

ASB creado

Lo último que quedaría por hacer sería anotar la cadena de conexión que posteriormente se empleará en el entorno de desarrollo elegido. Para ello, hay que pinchar en el icono “Connection information”, proporcionando dicha información.

ASB connection info

Funcionamiento

Este servicio puede utilizarse mediante diversos lenguajes (Java, Node.js, .NET, etc), a modo de ejemplo se hará en Python.
La instalación de Python y su correspondiente SDK no presenta complicaciones, habiendo versión para Windows, Linux y MacOS.
Una vez instalado el SDK, ya se está en disposición de crear y eliminar colas, así como introducir mensajes y extraerlos. Cabe señalar que en el propio portal clásico se pueden crear y eliminar colas.

Un código de ejemplo en Python sería el siguiente:

Conclusiones

La modalidad que se ha visto aquí es la más simple (paso de mensajes), pero también presenta otras más elaboradas. Comparándola con la Azure Storage Queue, su utilización es si cabe más sencilla y directa, pero no tan potente y versátil. Todo depende en realidad del uso que se le dé.

Hasta la próxima

Como podéis imaginar por el título de esta publicación, efectivamente se trata de una despedida, una que me cuesta muchísimo escribir. Esta semana del 9 de mayo ha sido la última como mánager del equipo de Enterprise IT y como empleado de Plain Concepts.

Sólo tengo buenas palabras para hablar de Plain Concepts, una empresa pura de ingeniería donde el talento corre por todos y cada uno de sus integrantes. Seguramente sea el peor momento para irme ahora que tenemos por las oficinas unas Microsoft Hololens y unas HTC Vive 🙂

He disfrutado muchísimo en los proyectos y apasionantes retos de esta empresa, de los cuales me he permitido el lujo de compartir detalles con todos los lectores de este blog a través de las publicaciones que he ido haciendo. Y aunque yo me vaya, aquí queda mucho crack: Antonio, Elena, Carlos, Manuel, José María, Jésica… Todos ellos hacen aportaciones interesantísimas en el ámbito de lo que tocan día tras días y consiguen que tenga este sitio en un lugar especial de mi lector RSS. Os echaré mucho de menos.

Inaugurar y escribir en este blog ha sido el más grande de los honores. Como sé que eventualmente nos vamos a ver y que este mundo no es tampoco tan grande, esto no es un adios sino un hasta la próxima.

¡Hasta la próxima cracks!
Carlos

PD: No podía irme sin dejaros algo en PowerShell aquí, así que cortesía de Dave Wilson os pongo algo de música en PowerShell:

Transferencia de datos utilizando Azcopy y Azure CLI

Una operación bastante común en la gestión de una cuenta de almacenamiento o Storage account en Azure es la copia de datos (se trate de un blob, fichero, etc) ya sea entre una cuenta y otra , o bien carga / descarga en local a Azure.
Estas operaciones pueden llevarse a cabo de diferentes maneras, pero aquí voy a centrarme en dos de ellas: AzCopy y Azure CLI. Decir que para los ejemplos sobre este último, se va a emplear el modo ARM, el cual se activa con:

Hay que resaltar que AzCopy resulta mucho más versátil y potente que Azure CLI, lo cual es lógico ya que es una herramienta creada específicamente para este fin, con lo cual contempla más situaciones y cuenta con más parámetros, permitiendo así una configuración mas específica. No obstante, AzCopy solo está disponible para Windows, mientras que Azure CLI es multiplataforma.

Sintaxis básica

Tanto AzCopy como Azure CLI pueden llevar a cabo la copia de blobs y ficheros.
Así, para subir un fichero a un blob y descargar todos los archivos de un blob de un container en Azure CLI en local:

Las opciones disponibles se pueden consultar acudiendo a la ayuda de Azure CLI:

Ayuda storage download Azure CLI

Por su parte, en AzCopy, para la descarga, se admiten más combinaciones más allá de la única descarga de un blob:

Y para la carga de archivos:

Respecto a la copia de blobs entre cuentas, en Azure CLI:

En AzCopy, esta misma operación puede realizarse de forma síncrona (se descarga una copia en local y esta se sube) o asíncrona (por defecto):

Llegados a este punto, a pesar de que Azure CLI también soporta la copia de archivos, al igual que AzCopy, sin embargo, este último también contempla además, otras características, por ejemplo, entre otras:

  • Importación / exportación de tablas en formato CSV o JSON.
  • Uso de un archivo de respuesta: en dicho archivo se permite especificar los parámetros al comando AzCopy, de modo que este los procesa como si hubieran indicado directamente:
  • Carpeta de archivo de diario: esta interesante funcionalidad permite reanudar operaciones inconclusas si detecta la existencia de este archivo.
  • Posibilidad de especificar el número de operaciones simultáneas a iniciar: por defecto, solo se puede llevar a cabo una operación en un mismo equipo. Esto es así para optimizar el uso de los recursos. Para realizar más de una simultáneamente, se emplearía el parámetro ‘/NC’

Conclusiones

Como se dijo al principio, AzCopy es mucho más versátil y potente a la hora de realizar copias. No hay que olvidar que el alcance de Azure CLI es la gestión de los recursos. Aún así, es perfectamente válida para las operaciones de copia habituales debido a su sencillez.

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!

DiskSpd, el sucesor de SQLIO

A la hora de medir el rendimiento de una unidad de almacenamiento, una de las herramientas más útiles y fiables (en entornos Windows) era SQLIO. A pesar de lo que su nombre pueda indicar, esta herramienta no servía para medir la E/S generada por una consulta SQL, sino para obtener medidas de rendimiento de disco. Sin embargo, después de algunos años entre nosotros, se podían apreciar señales de que poco a poco se estaba quedando fuera de su tiempo.

Entra DiskSpd

Finalmente, y tras su última actualización a finales del 2015, SQLIO fue retirado, y reemplazado por una nueva herramienta: DiskSPD. Al igual que su predecesor, se utiliza para obtener métricas de rendimiento de unidades de almacenamiento, pero con un conjunto de utilidades adicionales que lo convierten en algo mucho más útil. Además, y para los aficionados al Software Libre, su código fuente está disponible para descarga en GitHub, con una licencia MIT.

Ahora bien, entre todas las funciones, hay una característica particularmente interesante para los que desarrollamos scripts PowerShell: DiskSPD puede volcar la salida en formato XML. Esto es importante, porque facilita enormemente el procesado masivo de datos obtenidos mediante la ejecución de tests de diskspd.

Dentro de la carpeta de GitHub, hay un conjunto de scripts denominados VMFleet, que permite hacer operaciones y tests de forma masiva en máquinas virtuales, pero para aquellas personas menos ambiciosas que se conforman con testear el rendimiento de una única unidad, acompaño el artículo con un par de pequeños scripts para ejecutar baterías de tests. Obviamente, se pueden personalizar los parámetros de DiskSpd para simular lo más fielmente posible la carga de trabajo del servidor destino, pero como ejemplo ilustrativo basta.

El primero, lanza n ejecuciones de diskspd, bajo un cierto set de parámetros y recopila la salida en una serie de archivos XML en una carpeta especificada. Con $iteraciones podemos especificar el número de repeticiones del experimento, que se guarda en la carpeta especificada con $tag (que además personaliza el nombre del fichero xml generado). El parámetro $threads se usa para especificar cuántos hilos de trabajo deseamos lanzar simultáneamente, con lo que podemos poner, por ejemplo, un hilo por core del sistema.

El segundo script toma los XML de dicha carpeta, y calcula la velocidad media (en MB/s) de rendimiento del disco en base a los datos recopilados. Teniendo en cuenta que el rendimiento de un sistema puede variar a lo largo del tiempo por múltiples circunstancias, lo más realista es realizar varios experimentos idénticos, y promediarlos.

Process-SpeedData se encarga de promediar la velocidad de lectura/escritura y mostrar en pantalla el resultado, a partir de los archivos XML generados por el script anterior, para ello simplemente se le pasa como parámetro la carpeta que se desea escanear, y el script leerá y promediará la información de todos los XML que encuentre en la misma.

Resumiendo…

Aunque SQLio nos ha acompañado durante años y sigue siendo igual de funcional que antes, ahora disponemos de una herramienta igual de potente, más flexible y que además es Open Source. La capacidad de generar la salida en formato XML aquí es una característica diferenciadora que permite incorporar muy fácilmente la salida de información en scripts PowerShell que procesen los datos de rendimiento generados (latencia de acceso, velocidades medias, etc).