Cómo cortar internet a un moroso desde MikroTik automáticamente

Cada mes un porcentaje de tus clientes va a atrasarse en el pago. Cortarlos manualmente por Winbox no escala. Si tienes 200 clientes, ok. Si tienes 1.500, es imposible sin automatizar.

Este post cubre exactamente cómo lo hacemos en GestionaISP con MikroTik RouterOS 6.x/7.x. La técnica es simple, funciona sin scripts complejos, y sobrevive reinicios del router. Lo importante no está en la configuración base — está en la parte de auto-heal contra bugs silenciosos al final.

La arquitectura en 3 componentes

Necesitas tres piezas trabajando juntas:

Una address-list llamada cortados donde vas a poner las IPs de los clientes en mora.
Una regla de firewall que hace drop del tráfico de esa address-list.
Un sistema externo (tu software de gestión ISP) que agrega/quita IPs de esa lista según el estado de facturación de cada contrato.

Nada más. No necesitas PPPoE profile disabled, ni cambiar el perfil de la Simple Queue, ni scripts programados en el propio MikroTik. Todo eso lo empuja tu software externo.

Paso 1: crear la address-list

Por línea de comando (Terminal en Winbox):

/ip firewall address-list
add address=0.0.0.0/32 list=cortados comment="placeholder — sera reemplazado por IPs reales"

La entrada placeholder está solo para que la lista aparezca en la GUI. Cuando tu software agregue clientes reales, puedes borrar esta línea.

Paso 2: la regla de firewall

Esta es la regla que efectivamente corta el internet a los clientes en cortados. La ponemos en la cadena forward (para que corte el tráfico que atraviesa el router hacia internet, no el que va al router mismo):

/ip firewall filter
add chain=forward src-address-list=cortados action=drop comment="Cortar clientes morosos" place-before=0

El place-before=0 es crítico. Si no lo pones, la regla se agrega al final del firewall y las reglas de established/related anteriores permiten el tráfico de respuestas que ya está fluyendo. Poniéndola primero, ninguna conexión desde esa IP puede salir.

Si tu firewall tiene una arquitectura específica (mangle + fasttrack, PCC, etc.), ubica la regla en la posición equivalente antes de que fasttrack o accept la reevalúen.

¿No quieres armar esto a mano?

GestionaISP hace toda esta configuración por vos y agrega auto-heal en 2 minutos de instalación. Cloud desde USD 40/mes.

Probar demo

Paso 3: alta y baja programática desde tu software

Cuando un cliente pasa a estar en mora (X días desde vencimiento), tu software externo llama a la API de MikroTik y agrega su IP:

# Via API MikroTik (Python + librouteros)
api.path('/ip/firewall/address-list').add(
    address='192.168.100.42',
    list='cortados',
    comment='contrato_id=847 dia_corte=15'
)

Cuando el cliente paga, tu software remueve la IP:

# Buscar y borrar
for entry in api.path('/ip/firewall/address-list').select('.id', 'address').where(
    address='192.168.100.42', list='cortados'
):
    api.path('/ip/firewall/address-list').remove(entry['.id'])

Este patrón lo puedes replicar con la librería que uses (Node, PHP, Go). Lo importante es que sea atómico — o pagó y salió de la lista, o no pagó y sigue en la lista. Sin estados intermedios.

Paso 4: el problema real — bugs silenciosos

Hasta acá cualquier tutorial te lleva. El problema es lo que no te cuentan: la parte de "agregar a la lista al cortar" funciona bien. La parte de "quitar de la lista al pagar" falla.

¿Por qué?

El operador registra el pago pero olvida marcar "reactivar servicio" en tu software.
El pago se aplica a otra factura del cliente (múltiples contratos: CASA, LOCAL, PAPA) y el algoritmo no detecta cuál IP liberar.
La API del MikroTik responde 200 pero por un problema de red intermitente el remove no se aplica realmente.
El proceso de reactivación tira excepción a mitad de camino, dejando el estado inconsistente.

Resultado: el cliente pagó, tu software dice "activo", pero su IP sigue en cortados. Al día siguiente el cliente llama al operador: "estoy pagado pero no navego". El operador tarda 20 minutos diagnosticando algo que fue un bug silencioso.

Este problema no lo resuelves con "mejor código". Lo resuelves con reconciliación programada.

El auto-heal: reconciliación cada 3 minutos

La solución: un job programado que se pregunta cada 3 minutos:

"¿Hay IPs en la address-list cortados del MikroTik que pertenezcan a contratos activos y al día en mi base de datos?"

Si la respuesta es sí, remueves esas IPs. Ese es todo el algoritmo.

Pseudocódigo:

def reconciliar_cortados():
    # 1. Leer la lista completa de address-list "cortados" del MT
    ips_en_cortados = mikrotik.get_addresslist('cortados')

    # 2. Para cada IP, buscar el contrato correspondiente en BD
    for ip in ips_en_cortados:
        contrato = db.query(Contrato).filter_by(ip_asignada=ip).first()
        if not contrato:
            continue  # IP en la lista pero sin contrato — ignorar

        # 3. Si el contrato es ACTIVO y sin deuda, remover del MT
        if contrato.estado == "activo" and contrato.saldo_total == 0:
            mikrotik.remove_from_addresslist('cortados', ip)
            log.warning(f"Auto-heal: removida {ip} del cortados (contrato {contrato.id})")
            db.add(EventoAudit(
                contrato_id=contrato.id,
                tipo="auto_heal_cortados",
                detalle=f"IP {ip} estaba en cortados pese a contrato activo"
            ))

Corriendo este job cada 3 minutos, el peor caso posible es que un cliente que acaba de pagar espere hasta 3 minutos para navegar. Sin auto-heal, podría esperar horas o hasta que un operador atienda el reclamo.

Métricas de este approach en producción

En VisualNet (el ISP que construyó GestionaISP) llevamos 4 meses con este esquema en 700+ contratos. Datos reales:

Métrica	Valor
Ciclos de auto-heal ejecutados por día	480 (cada 3 min)
Casos reparados por día (mediana)	2-4
Casos reparados en día pico (post-cierre mes)	18
Tickets "pagué y no navego" ANTES del auto-heal	~12/día
Tickets "pagué y no navego" DESPUÉS del auto-heal	<1/día

El auto-heal soluciona el 95% de los casos por sí solo. Los pocos que quedan son problemas reales (ONU caída, cable cortado) que necesitan intervención humana.

Errores comunes que ves en tutoriales

Error 1: usar PPPoE profile "disabled"

Es tentador. Marcas al usuario como disabled en el PPPoE server y no se conecta. El problema: al desmarcarlo, el cliente tiene que reconectar (reiniciar router). El address-list es transparente — el cliente no nota nada al reactivarse, no tiene que rebootear.

Error 2: cambiar la Simple Queue a 1kbps en lugar de cortar

"Le dejamos 1kbps para que sepa que sigue conectado pero sin navegar." Cliente termina reclamando que el internet "funciona pero lentísimo". No corte "elegante" — o corte, o no cortes.

Error 3: cortar en la cadena input en vez de forward

La cadena input solo bloquea tráfico hacia el router mismo, no el que atraviesa hacia internet. Tiene que ser forward.

Error 4: no versionar la configuración del firewall

Si un colega toca una regla y rompe el corte, no vas a saber qué cambió. Usar /export file=backup-firewall periódicamente y guardar los .rsc en un repo git.

Cierre

El corte automático desde MikroTik son 20 minutos de configuración. Lo que separa una implementación amateur de una profesional es la reconciliación programada — el auto-heal. Sin él, siempre vas a tener clientes atrapados en la lista tras pagar.

En GestionaISP esto viene incluido. Ni siquiera se puede desactivar — es parte de la arquitectura. Puedes ver el código exacto que ejecutamos en el agente Simón cuando le preguntás por diagnósticos de "cliente no navega tras pago".

¿Vale la pena armarlo o comprar hecho?

Si tienes menos de 100 clientes, armá tu propio script. Si tienes más, el tiempo de mantenerlo cuesta más que USD 40/mes de GestionaISP.

Ver precios