Construimos un VPN Control Center para el equipo de una agencia.
Una agencia multimarca pidió autoservicio sobre el acceso seguro que operamos para ella: dar de alta a un usuario, restablecer una contraseña, dar de baja a alguien que se marchó, todo desde su propio equipo. Esto es lo que construimos, y por qué es una de las jugadas de servicio gestionado más fuertes que conocemos.
En este artículo 4 secciones
- Una agencia multimarca pidió autoservicio sobre la VPN que operamos para ella: dar de alta a un usuario, restablecer una contraseña, dar de baja a alguien que se marchó, sin abrir un ticket.
- La petición: construyan a mi propia gente las herramientas, tan fáciles que un operador junior pueda usarlas sin romper nada.
- Convertimos nuestro toolkit interno de operador en una plantilla para sus gateways (una sola fuente de verdad, generada por gateway), y después construimos un VPN Control Center dentro del área de cliente: acceso por roles, reglas por usuario y un flujo de descubrimiento y alta para gateways nuevos.
- Estado final: su equipo lleva el acceso seguro del día a día desde un menú. Nosotros tenemos la infraestructura de debajo.
Los cambios rutinarios de la VPN de la agencia nos llegaban como solicitudes. Dar de alta a un usuario. Restablecer una contraseña. Dar de baja a alguien que se fue. La agencia pidió el siguiente paso: poner esas operaciones cotidianas en manos de su propio equipo, para marcar su propio ritmo.
La petición, en resumen: construir las herramientas para que las use su propia gente, tan sencillas que el operador más junior pueda usarlas sin romper nada.
h2 (#why-us): Por qué nos lo pidieron a nosotros, y no a una consola
Porque aquello sobre lo que querían autoservicio era infraestructura que nosotros diseñamos y operamos: los gateways, las autoridades de certificación por tenant, el ciclo de vida de las credenciales. Cualquier otro habría tenido que hacer ingeniería inversa de la instalación primero. Nosotros podíamos acertar la abstracción al primer intento, porque construimos aquello que abstrae.
h2 (#one-toolkit-not-three): Un toolkit, no uno por tenant
Varios tenants, gateways separados, autoridades de certificación separadas, y las herramientas tenían que funcionar de forma idéntica en todos para que el cliente aprendiera un solo flujo de trabajo. La jugada limpia no era escribir a mano scripts por tenant, que es mantenimiento multiplicado y drift garantizado. Tratamos nuestro propio toolkit interno de operador como plantilla y generamos el conjunto de cada tenant a partir de ella, sustituyendo las constantes por gateway.
En concreto: cinco operaciones canónicas (alta de usuario, restablecimiento de contraseña, baja de usuario, listado de usuarios, rotación de credenciales), generadas por gateway, cada script hablando solo con su propio gateway a través de la REST API de OPNsense, con credenciales rotables y todo ejecutándose en local sin ningún servicio externo en el circuito. Después, la capa de experiencia de operador que el cliente pidió realmente: una tabla maestra de referencia, un how-to por gateway y un banner de inicio de sesión que indica a cualquier operador exactamente el comando que necesita.
=== secure-access operator toolkit ===
add-user | reset-password | remove-user | list-users | rotate-api-credentials
per-gateway how-to: /etc/<gateway>-howto reference: /etc/vpn-operationsSe lee con cat desde cualquier sesión. La red de seguridad del operador junior es un banner, no una página de wiki que nadie abre.
h2 (#the-control-center): El Control Center en el área de cliente
Después llegó el momento del «¿podrían también?», y el toolkit se convirtió en una función de producto. Un VPN Control Center dentro del área de cliente: un módulo de menú con control de acceso por roles, un selector de gateway, un editor de reglas de acceso por usuario y un flujo de alta de gateway con descubrimiento automático. Pegue la URL, la key y el secret de un gateway, pulse descubrir, y el módulo lee la autoridad de certificación y la instancia de la máquina y lo da de alta sin código nuevo.
Los cambios rutinarios de usuarios los hacía nuestro equipo, bajo solicitud.
Scripts de operador generados para cada tenant
Sus operadores se sirven solos. Nosotros mantenemos una plantilla.
Un Control Center en el área de cliente
Acceso por roles, y gateways nuevos que se dan de alta solos mediante descubrimiento.
En cada paso, el cliente nos confió más de la construcción, no menos.
h2 (#the-end-state): El estado final
En producción. Cuando llegó un gateway nuevo, se dio de alta solo a través del flujo de descubrimiento, sin escribir código nuevo para él. Su equipo lleva el acceso seguro del día a día desde un menú, cada gateway futuro se da de alta solo, y nosotros tenemos la infraestructura de debajo mientras el cliente conduce.
“Operamos la VPN y entregamos a su equipo los mandos, y nos quedamos las llaves de la sala de máquinas.”
Respuestas directas
¿Puede mi propio equipo gestionar usuarios de VPN sobre infraestructura gestionada?+
Sí, y puede hacerse con buena ingeniería. En esta construcción los operadores del cliente recibieron herramientas generadas y después un módulo del área de cliente con acceso por roles, sobre gateways que operamos nosotros.
¿Construye EuroVPS herramientas a medida para clientes?+
Cuando la colaboración lo requiere. Esta pasó de scripts de operador a una función del área de cliente en producción.
¿Puede gestionarse OPNsense a través de su API?+
Sí. Cada operación de esta construcción pasó por la REST API de OPNsense y no por la consola, que es nuestra regla de la casa, porque las operaciones por script son repetibles y revisables.
¿Quién cuida las herramientas de autoservicio?+
Nosotros. El autoservicio traslada las operaciones rutinarias a su equipo, mientras los gateways, las autoridades de certificación y el propio módulo siguen siendo nuestra responsabilidad.
¿Es segura la gestión de accesos en autoservicio para personal junior?+
Esa fue la especificación de diseño, literalmente: tan fácil que el operador más junior pueda usarla sin romper nada. Las barreras de protección viven en las herramientas (un comando por tarea, acceso por roles en el área de cliente), no en un documento de advertencia que nadie lee.
¿Quiere que su equipo lleve sus propias operaciones?
Díganos qué operaciones le gustaría a su equipo poder ejecutar por sí mismo. Si la respuesta correcta son herramientas, construiremos los mandos y nos quedaremos la infraestructura de debajo.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero