Meraki self-service App - Algo de redes

Tabla de Contenidos

Introducción

Como consecuencia de la pandemia de COVID-19, varias organizaciones decidieron brindar a sus empleados equipos de red para que instalen en sus casas. Estos equipos levantan la conexión VPN hasta algún concentrador, y proveen un SSID corporativo que permite a los usuarios acceder a recursos internos.

Una de las formas de implementar estas soluciones es usando tecnología Cisco Meraki. Meraki provee equipos específicos para trabajadores remotos, como el modelo Z3. Las ventajas más importantes que tiene usar Meraki en este tipo de soluciones son:

Administración y monitoreo centralizado en la nube.
Escala a miles de dispositivos
Meraki AutoVPN facilita el despliegue de VPNs al usar enlaces de internet hogareños.
Funciones enterprise-grade como redundancia de concentradores VPN y 802.1X en la red wireless.

Desafíos de la solución Out-of-the-box

Sin embargo, todavía se plantean algunos desafíos al momento de escalar estos despliegues. Porque hay que definir cómo se configuran los equipos para identificar cuál pertenece a qué usuario. Hacer esto va a facilitar el monitoreo y troubleshooting. Además, identificar al usuario implica poder brindar acceso segmentado a los distintos recursos empresariales.

Dentro de la primer categoría de desafíos, que podrían llamarse de negocio, hay dos puntos a resolver:

Desplegar equipos en las casas de cada usuario y controlar qué equipo se entrega a qué usuario va a sobrecargar de trabajo al equipo de IT.
Se está extendiendo la frontera de la red interna a la casa de cada usuario. Mantener la seguridad es crítico, y los usuarios deberían tener el mismo acceso que tienen en las oficinas (no más).

Por otro lado, la solución de Meraki (y más específicamente los equipos Z3) tienen algunas limitaciones en cuanto a las opciones de configuración:

El SSID corporativo puede desplegarse con 802.1X y usar un servidor RADIUS (como Cisco ISE) para comprobar las credenciales contra Active Directory. El problema es que en los dispositivos Meraki Z/MX no se pueden usar estas credenciales para dar acceso diferenciado a los usuarios. No es posible asignarles políticas de autorización por grupo de AD (como sí ocurre en los despliegues de wireless en oficina).
Si se opta por brindar también un SSID para uso personal, que solo brinde acceso a Internet, el usuario no podrá elegir su PSK ya que para esto debe tener acceso a Meraki Dashboard.

Discusión sobre onboarding

El punto de onboarding es uno de los más críticos ¿Cómo se van a entregar los equipos a los usuarios? Las dos alternativas que se soportan de forma nativa en Meraki serían: asignar manualmente cada usuario a un Serial Number y aplicarle las políticas (opción más lenta), o entregar un equipo aleatorio a cada usuario (poco seguro y difícil de monitorear).

La imagen puede ayudar a aclarar esta discusión:

Solución: Una aplicación de autogestión

Crear una aplicación para que sean los mismos usuarios quienes realicen el onboarding del dispositivo que llega a sus hogares. Esta es una solución muy interesante a los desafíos que se analizaron en la sección anterior. Una aplicación web por ejemplo, accesible desde internet (ya que hasta finalizado el onboarding los usuarios no tendrán VPN). Sin embargo el frontend puede ser variado, y dependerá de cada organización. Las alternativas pueden ser un bot en un servicio de mensajería, o integrar el proceso de onboarding en otra aplicación ya existente.

La aplicación que vamos a ver a continuación busca simplificar el trabajo de TI, brindar a los usuarios una herramienta paso a paso, y mantener la segmentación por grupo de usuarios. Es un ejemplo de lo que se puede lograr mediante la automatización de este tipo de despliegues. Estas son las características a destacar:

Accesible desde internet.
Los usuarios no tienen que generarse nuevas credenciales, se usan las corporativas en Azure Active Directory. Al ser una aplicación web, se integra mediante SAML.
Una vez autenticados, se presentan workflows guiados a los usuarios para pedirles los datos del equipo que recibieron (el Serial Number) y enseñarles a conectarlo.
El backend de la aplicación toma los datos de usuario y el Serial Number del dispositivo y usa las APIs de Meraki para crear una red para este usuario.
El grupo al que pertenezca el usuario definirá qué plantilla se usa para el dispositivo hogareño. Cada plantilla permite el acceso a determinadas subredes.
El usuario puede volver a esta aplicación en cualquier momento y auto-gestionar su contraseña para el SSID personal (PSK, sólo acceso a Internet) o realizar un cambio de dispositivo por uno con Serial Number diferente.
El equipo de TI sigue operando la red usando únicamente Meraki Dashboard. Todas las redes creadas de forma automatizada son nombradas y tagueadas con información relevante del usuario y grupo.

Nota: Yo no soy programador, y solo hago estos desarrollos para demostraciones conceptuales. Esta aplicación no fue nunca pensada para ser puesta en producción, y no recomiendo hacerlo. Pueden sin embargo reutilizar partes del código que les sean útiles, o seguir su lógica para realizar las configuraciones necesarias en Meraki.

El video siguiente muestra en forma muy resumida el resultado:

No se va entrar en detalle de cómo funciona la aplicación en este post. El código de la misma está publicado en un repositorio público para que cualquiera pueda usarlo o adaptarlo (aunque obviamente pueden hacerme cualquier pregunta al respecto).

lucasscola / meraki-teleworker-app

A web portal intended to be used by end users that receive Meraki gear at their homes. It eases IT work by allowing customers to self register their devices. It also allows editing the personal SSID password for their family use.

Lo que sí se va a analizar es cómo es la lógica y la interacción con Meraki. Esto es lo que explica la sección siguiente.

Interacción de la aplicación con la nube de Meraki

Requisitos previos en Meraki

En primer lugar, lo básico es tener una organización en Meraki con las APIs habilitadas. Como recomendación, crear un usuario sólo para acceso via APIs. En segundo lugar, deben cargarse todos los dispositivos al inventario de esta organización. La aplicación luego hará claim de estos dispositivos asociándolos a redes particulares.

Blueprints

La forma más eficiente de trabajar en este tipo de aplicaciones es tener plantillas, o blueprints. Cada plantilla va a estar asociada con un grupo de usuarios. Por lo tanto, la diferencia entre una plantilla y otra será a qué redes se puede acceder una vez conectado al equipo.

Meraki posee la funcionalidad de Templates y es válido pensar en aprovechar esta función. Su primer ventaja es que, si se necesita hacer un cambio sobre alguno de los grupos, solo actualizando el Template se actualizarán todas las redes asociadas a él. La segunda ventaja es el auto-direccionamiento IP de todas las pequeñas subredes a desplegar en cada dispositivo hogareño, evitando que estas se superpongan. Si alguno está interesado en conocer más de la funcionalidad, la documentación está en este link.

Sin embargo, en la aplicación no se usaron Templates ¿Por qué? Al tener redes de Meraki asociadas a Templates se pierde la flexibilidad de configuraciones únicas por equipo. En particular se perdía la posibilidad de asignar diferentes PSK a la red Wi-Fi personal. Para evitar esta y otras limitaciones que pudieran surgir, la funcionalidad de Templates no fue implementada en la aplicación y se hablará entonces de blueprints para no confundir.

Un blueprint es una red en Meraki (una red, no un template). En ella se definen todas las características que se necesitan. Por ejemplo:

VPN hacia concentradores.
Access Control Lists.
Subred LAN corporativa en el equipo (dummy, será modificada por la aplicación).
Subred LAN personal (solo para acceso a Internet, se repite en todos los equipos).
SSID corporativo con autenticación 802.1X
SSID personal con autenticación PSK (password dummy, será modificado por la aplicación)

Durante el proceso de onboarding estos blueprints serán clonados para crear nuevas redes y dar de alta en ellas al dispositivo Z/MX. Clonar redes es otra característica de Meraki, una que sí se aprovecha en la aplicación

Nota: Algo importante a tener en cuenta es que para poder crear los blueprints adecuadamente se debe asociar un dispositivo Z/MX. Si no se hace no se podrá configurar las opciones de seguridad y Wireless desde Meraki Dahsboard. Cuando el blueprint esté configurado, se desasocia el equipo (la configuración se puede seguir viendo y modificando por APIs).

Nota 2: Un consejo, usar un nombre lógico en los blueprints (nombre de la red Meraki) para ayudar a los administradores a identificarlos. En mi caso, por ejemplo, los nombres eran ”App-Blueprint-<Grupo-AD>”.

Funciones de la aplicación

Pasemos ahora a la aplicación en sí. En el repositorio se encuentra configuración necesaria para que desplegarla (integración tanto con Meraki como con Azure AD, por ejemplo). Pero haciendo un repaso a alto nivel, estas son sus tareas.

Debe obtener del usuario sus credenciales. Para esto usa autenticación SAML contra Azure AD. De aquí trae el nombre de usuario y el grupo al que pertenece.
Debe pedirle al usuario el Serial Number del equipo Meraki que recibió.
Con los tres datos obtenidos de los pasos anteriores va a seleccionar el blueprint asociado con el grupo del usuario. Creará una nueva red en Meraki clonando este blueprint.
- Usará el nombre de usuario para nombrar esta red. De esta forma luego será fácil de filtrar y monitorear o hacer troubleshooting de la misma.
- Para poder hacer cambios masivos en todas las redes asociadas al mismo blueprint (ya que no se usan Templates) se aplican Tags. La nueva red tendrá un tag con el nombre de su blueprint, y otro tag genérico que la identifica como red de teletrabajo.
- En esta nueva red debe asignarse el segmento para la LAN que accederá a los recursos corporativos. La aplicación se ocupa de segmentar una superred (configurada al desplegarla). Garantiza que no se superpone con el segmento de ninguna otra red.
- Asignará una PSK aleatoria para la red Wi-Fi personal.
Con la red creada en Meraki, asocia a esta el dispositivo Z/MX.
Guarda en una base de datos la información de este usuario, para luego permitir que el mismo realice modificaciones en la misma. Dos ejemplos son: cambiar PSK personal, o hacer un cambio de equipo en caso de avería.

Endpoints usados de las Dahsboard APIs de Meraki

Para dejar como referencia, estos fueron los endpoints más importantes que se usan en la aplicación para las distintas funcionalidades. Las APIs de Meraki que aparecen a continuación corresponden con las Dashboard APIs v1 documentadas en este link. Pueden usar este enlace para ver más detallas sobre cómo construir las llamadas.

GET /organizations/{organizationId}/inventoryDevices/{serialNumber}

Una comprobación rápida para saber si el SN del dispositivo fue cargado en la Organización de Meraki. Solo chequeando que el status de la respuesta sea 200 es suficiente.

POST /organizations/{organizationId}/networks

Se crea una nueva red para el equipo a dar de alta. Lo más importante de esta llamada es indicar en el cuerpo de la misma que se debe clonar la configuración desde el blueprint, incluyendo el campo copyFromNetworkId con el ID de la red blueprint como valor.
Si la operación fue creada de forma exitosa, tendremos en el cuerpo de la respuesta el campo id identificando la nueva red. Este valor se usará para configurar las demás características con llamadas posteriores.

PUT /networks/{networkId}/appliance/vlans/10

Este endopint se usa para modificar la subred de la VLAN 10. Esta VLAN es la que se propaga por la VPN y se usa en el SSID corporativo, por lo tanto su subred asociada debe ser única. Una vez que la aplicación calcula una subred no usada, la envía en el cuerpo de esta llamada, en los campos subnet y applianceIp. El valor de este último campo indica el default gateway de la subred, que en este caso es la primera IP.

GET /networks/{networkId}/appliance/vpn/siteToSiteVpn

Con este endpoint se recupera la información de los concentradores VPN cuando networkId se corresponde con el del blueprint a clonar.

PUT /networks/{networkId}/appliance/vpn/siteToSiteVpn

Una vez obtenidos los datos de VPNs del blueprint, se usan para modificar los de la red del dispositivo que se está dando de alta. Para esto, networkId en esta llamada equivale al ID de la nueva red. Se necesita modificar la configuración de VPN ya que en ella se indica la subred local a conectar. El campo subnets lleva como objetos la subred que configuró la aplicación para la VLAN 10. Su estructura está mejor detallada en la documentación.

POST /networks/{networkId}/devices/claim

Se usa esta llamada para agregar dispositivo del usuario a la red nueva creada. Hay que indicar el Serial Number dentro de un array en el campo serials.

Además de todos estas llamadas, para construir la nueva red se necesita asignar la PSK para la red personal de los usuarios. El problema es que, al momento de desarrollar la aplicación, las Dashboard APIs v1 no tenían un endpoint que permitiese controlar los SSIDs de un MX/Z. Por eso, como workaround, se uso un endpoint de las Dashboard APIs v0.

PUT https://api.meraki.com/api/v0/networks/{networkId}/ssids/{ssidNumber}

Este endopint permite modificar el SSID, que se identifica como ssidNumber = 2. El cuerpo de la llamada tiene la nueva contraseña en el campo psk.

Sin embargo, revisando la documentación mientras escribía esta entrada, parece que en Dashboard APIs v1.25.0 se agregó el endpoint necesario. No he tenido oportunidad todavía de probarlo, pero para quién quiera hacerlo, se encuentra aquí.

Aquí concluye esta entrada, y aprovecho para invitar a cualquiera que necesite utilizar las características de la aplicación a revisar el repositorio para entender en más detalle el código. Nuevamente, como se utilizó solo para pruebas de concepto puede contener errores y no está lista para desplegar en producción. Pero es una buena forma de aprovechar el potencial de estas soluciones y optimizar el trabajo.

Espero que este post haya sido de interés. Cualquier duda se pueden poner en contacto conmigo a través de los comentarios o de mis redes sociales.

Autogestión de equipos Meraki para teletrabajadores