Cómo automatizar cortes y reconexiones en Mikrotik sin complicarte

En el día a día de un proveedor de servicios de internet (ISP), hay pocas tareas técnicas tan monótonas y propensas a errores como deshabilitar y habilitar abonados en los routers. Cuando lo haces a mano, estás a un clic de cortar la conexión del cliente equivocado o de retrasar la reconexión de un abonado que ya pagó y está reclamando por teléfono.

Para solucionar esto, Mikrotik RouterOS ofrece excelentes mecanismos para automatizar este flujo. En esta guía técnica, te explicamos los métodos reales que usan los ISPs para gestionar cortes y reconexiones en Mikrotik, con sus ventajas y limitaciones, para que elijas el que mejor se adapte a tu operación.

1. Los métodos de integración con Mikrotik: ¿Netwatch, Scripts o API?

Existen distintas formas de lograr que tu router Mikrotik aplique cortes de forma automatizada. Estas son las más utilizadas:

A. Scripts internos y Netwatch (Control local)

Consiste en configurar scripts dentro de RouterOS que se ejecutan automáticamente cada cierto tiempo o cuando Netwatch detecta un cambio en la red (por ejemplo, si una IP responde al ping o no).

Para qué sirve: Tareas básicas y de respaldo locales, como mandar un ping y ejecutar una acción sencilla de failover.
Por qué no sirve para cortes masivos: No escala. Escribir y sincronizar scripts individuales en el router para cientos de usuarios es una pesadilla de mantenimiento que puede saturar la CPU del Mikrotik si la lógica se vuelve muy pesada.

B. Integración mediante la API de RouterOS (Control externo)

Es la vía más utilizada por sistemas de gestión. Un software externo se conecta de forma segura a tu router mediante el puerto API de Mikrotik para enviar comandos de corte o reconexión.

Para qué sirve: Centralización completa. Si registras un cobro o el vencimiento de una factura en tu software, el sistema envía la orden vía API para deshabilitar o habilitar al cliente sin que tengas que entrar al Winbox manualmente.
Por qué es el método recomendado: No consume recursos extras de CPU en el router manteniendo scripts locales pesados, y permite centralizar todo el control desde una única interfaz web. Es especialmente útil para operadores que manejan múltiples routers en distintas zonas.

2. Los métodos reales de corte: ¿cuál conviene según tu operación?

En la práctica, los ISPs que usan Mikrotik aplican distintas técnicas para suspender el servicio de un cliente moroso. Cada una tiene ventajas y limitaciones reales que debes conocer antes de elegir:

A. Deshabilitar el perfil o secreto PPPoE

Es el método más directo: se desactiva el secret PPPoE del cliente en el router, lo que impide que su equipo se autentique y establezca la sesión.

Ventaja: Es limpio desde el punto de vista del router. La sesión se elimina y no consume recursos de colas ni firewall.
Desventaja: El cliente ve un error genérico de conexión ("Sin acceso a internet" o "Error de autenticación") y muchas veces asumirá que hay una avería en tu red, generando llamadas a soporte.
Riesgo operativo importante: Si desactivas masivamente cientos o miles de sesiones PPPoE, cuando esos clientes paguen o se reactiven, todos intentarán reconectarse al mismo tiempo. Esto genera lo que se conoce como efecto "thundering herd" (estampida): el router y/o servidor RADIUS se saturan procesando miles de solicitudes de autenticación simultáneas, lo que puede provocar timeouts, sesiones incompletas y, en casos extremos, la necesidad de reiniciar el equipo.

B. Reducir el ancho de banda a 0 kbps (o un valor mínimo)

En lugar de desconectar al cliente, se modifica su cola (Queue) para asignarle un ancho de banda de 0 kbps o un valor extremadamente bajo (por ejemplo, 32k/32k). El cliente queda técnicamente conectado, pero no puede navegar.

Ventaja: Evita el efecto "thundering herd" porque los clientes nunca se desconectan. Al momento de la reconexión, solo se actualiza el límite de su cola — no hay solicitud de autenticación masiva.
Ventaja adicional: Muchos operadores reportan que este método es más estable en redes con miles de abonados, ya que no genera picos de carga en el router al momento de activaciones masivas.
Desventaja: El cliente sigue consumiendo un recurso de cola en el router (aunque mínimo). Además, sin una notificación clara, el cliente puede pensar que su internet "está lento" en lugar de entender que fue cortado por falta de pago.

C. Redirección a portal de aviso (Address Lists + NAT)

Consiste en agregar la IP del cliente moroso a una Address List en el firewall y redirigir su tráfico HTTP hacia una página web que le informa sobre su deuda y cómo pagar.

                    /ip firewall address-list add list=Morosos address=192.168.10.50 comment="Abonado Juan Perez"
                

                    /ip firewall nat

                    add chain=dstnat src-address-list=Morosos protocol=tcp dst-port=80 action=dst-nat to-addresses=10.0.0.5 to-ports=8080 comment="Redireccion a Pagina de Deuda"

Ventaja: Es la mejor experiencia para el cliente. En lugar de ver un error genérico, lee un mensaje claro indicando que su servicio fue suspendido y cómo regularizar su pago.
Limitación importante: Este método solo funciona con tráfico HTTP (puerto 80). Hoy en día, la gran mayoría de sitios web usan HTTPS, y los navegadores modernos implementan HSTS (HTTP Strict Transport Security). Esto significa que al intentar redirigir tráfico HTTPS, el navegador mostrará un error de certificado SSL en lugar de tu página de aviso. En la práctica, muchos operadores han dejado de usar este método como solución principal por esta limitación.
Recomendación: Si decides implementarlo, úsalo como un complemento, no como tu único método de corte. Combínalo con notificaciones previas por SMS, correo o WhatsApp para que el cliente sepa que su servicio será suspendido antes de que ocurra.

¿Cuál es el más usado en la práctica? No existe un método único "correcto". Muchos ISPs pequeños y medianos prefieren reducir el ancho de banda por su estabilidad operativa, mientras que operadores más grandes con infraestructura RADIUS optan por deshabilitar sesiones PPPoE con desconexión controlada (CoA). Lo importante es que tu sistema de gestión te permita elegir y automatizar el método que mejor se adapte a tu red.

3. Prácticas recomendadas de seguridad para proteger tu Mikrotik

Conectar la API de tu Mikrotik a un sistema externo requiere seguir medidas estrictas de seguridad para evitar intrusiones en tu red:

1. No uses el puerto API por defecto: Por defecto, el API trabaja en el puerto 8728 (y 8729 para SSL). Cámbialos por puertos personalizados en /ip service.
2. Limita el acceso por IP (IP Whitelisting): Configura la directiva address en el servicio API para que el Mikrotik rechace cualquier conexión que no provenga de la dirección IP específica del servidor de tu software de gestión.
3. Crea un usuario exclusivo para la API: Nunca entregues las credenciales del usuario admin a sistemas externos. Crea un usuario en /user con permisos exclusivos de lectura/escritura (write y read), pero desactiva los permisos de políticas y configuración profunda (policy, ssh, winbox).
4. Usa conexiones persistentes: Si tu sistema envía muchos comandos, asegúrate de que use una conexión API persistente en lugar de abrir y cerrar una sesión por cada operación. Esto reduce la carga en el router y evita problemas de rendimiento.

4. Cómo automatiza SICAV los cortes y reconexiones

Configurar estas reglas, mantener la sincronización entre tu sistema de facturación y cada router, y aplicar la seguridad adecuada de forma manual requiere conocimientos técnicos y tiempo constante. SICAV simplifica este proceso integrándose directamente con la API de RouterOS:

Integración con la API de Mikrotik: Registras los datos de conexión de tu router en la plataforma SICAV (bajo protocolos seguros) y el sistema se encarga de automatizar el flujo. Cuando se cumple el plazo de vencimiento que tú configuras, SICAV envía los comandos correspondientes al Mikrotik para aplicar el corte. Cuando el cliente paga — ya sea a través de la plataforma, en caja o en un punto de pago integrado — el sistema procesa la reconexión automáticamente, sin que tu equipo técnico tenga que intervenir.

¿Cortes masivos? SICAV puede procesar lotes de cortes y reconexiones a través de la API, lo que permite gestionar la cartera completa de morosos de forma organizada. No es un proceso que ocurra en un parpadeo — depende de la cantidad de abonados y la capacidad de tu router — pero elimina por completo la necesidad de hacerlo uno por uno desde el Winbox.

Conclusión

Automatizar los cortes y reconexiones no es solo una cuestión de ahorro de tiempo (que también lo es). Es una decisión que impacta directamente en la experiencia de tus abonados y en la estabilidad operativa de tu red. Un sistema que reconecta automáticamente cuando el cliente paga — a cualquier hora del día — reduce los reclamos, libera a tu equipo técnico y proyecta una imagen profesional de tu empresa.

Si actualmente estás gestionando cortes de forma manual o con scripts artesanales que dejan de funcionar cuando menos lo esperas, considera evaluar una solución que centralice y automatice todo el proceso de forma confiable.