Aprovisionar un cliente
Flujo técnico completo, de código a infraestructura, al contratar/suspender/activar un servicio de internet.
Esta página describe qué pasa realmente por debajo cuando, desde el dashboard, se contrata, suspende o reactiva el servicio de un cliente. Útil para diagnosticar por qué un cliente "no tiene internet" a pesar de que su factura está pagada, o viceversa.
Provisión (alta de servicio)
internet-services.service.ts orquesta, en este orden:
- Crea el cliente y el servicio en la base de datos (Postgres vía Prisma).
- RouterOS — crea el usuario PPPoE (usuario, contraseña, perfil de velocidad según el
plan) y la simple queue con el límite de ancho de banda. Se ejecuta vía
RouterOSService.withConnection, que decide automáticamente:- Si el tenant tiene un Agente Local conectado para ese router → relaya el comando por WebSocket al agente.
- Si no → se conecta directo a la API de Mikrotik (requiere IP pública alcanzable).
- RADIUS — escribe las entradas correspondientes en
radcheck/radreply(ver FreeRADIUS para el estado real de esto en producción — hoy es principalmente el interruptor de suspensión, no la fuente de verdad de la contraseña PPPoE).
Si el paso de RouterOS o RADIUS falla (router offline, agente desconectado), el servicio
queda marcado con un deviceSyncPending — hay un job en segundo plano
(device-sync queue) que reintenta automáticamente.
Suspensión (por mora)
Al cortar automáticamente (8am diario) o manualmente:
- Deshabilita el usuario PPPoE en el Mikrotik.
- Desconecta cualquier sesión PPPoE activa de ese usuario.
- Agrega al cliente a una lista de direcciones de firewall (
address-list) — útil como capa adicional de bloqueo incluso si el PPPoE fallara al deshabilitarse. - Bloquea en RADIUS (fila
Auth-Type := Reject).
Activación (al pagar)
Revierte cada uno de los 4 pasos anteriores, en el mismo orden, y fuerza una reautenticación del cliente (para que no tenga que reiniciar su router manualmente).
Cambios masivos
Para operar sobre muchos servicios a la vez (regularizar planes tras un cambio de precio, subir de velocidad a todo un plan, re-sincronizar tras una falla masiva del agente), estas operaciones se encolan en segundo plano en vez de ejecutarse en la misma petición HTTP — ver Desarrolladores → Colas (BullMQ) para el detalle de cada cola y su processor.