Configuración de MikroTik

Ajustes de la conexión a la API de MikroTik RouterOS.

Conexión

mikrotik.address Obligatorio

Env: MIKROTIK_HOST · Por defecto: — (obligatorio)

Dirección de la API de RouterOS en formato host:port. No tiene valor por defecto: el bouncer termina con mikrotik.address is required si el valor está vacío. El 192.168.0.1:8728 que se usa más abajo es el valor de ejemplo incluido en config/cs-routeros-bouncer.yaml, no un valor por defecto.

• Puerto 8728 — API en texto plano
• Puerto 8729 — API cifrada con TLS

mikrotik:
  address: "192.168.0.1:8728"

mikrotik.username Obligatorio

Env: MIKROTIK_USER · Por defecto: — (obligatorio)

El nombre de usuario de la API de RouterOS. No tiene valor por defecto: el bouncer termina con mikrotik.username is required si el valor está vacío. El nombre crowdsec es el valor de ejemplo incluido en config/cs-routeros-bouncer.yaml, no un valor por defecto. Usa un usuario dedicado con permisos mínimos. Consulta Configuración del router para crear el usuario.

mikrotik.password Obligatorio

Env: MIKROTIK_PASS · Por defecto: — (obligatorio)

La contraseña de la API de RouterOS.

Variables de entorno

Para valores sensibles como contraseñas, usa variables de entorno en lugar del archivo de configuración:

export MIKROTIK_PASS="your-secure-password"

TLS

mikrotik.tls Opcional

Env: MIKROTIK_TLS · Por defecto: false

Habilita TLS para la conexión a la API de RouterOS. Requiere el servicio api-ssl en el router (puerto 8729).

mikrotik:
  address: "192.168.0.1:8729"
  tls: true

mikrotik.tls_insecure Opcional

Env: MIKROTIK_TLS_INSECURE · Por defecto: false

Omite la verificación del certificado TLS. Solo es necesario cuando el router usa un certificado autofirmado.

Precaución

Mantén tls_insecure: false siempre que sea posible: la configuración recomendada en producción es un certificado firmado por una CA en la que confíe el host del bouncer, de modo que la conexión quede cifrada y verificada. Establece tls_insecure: true solo para certificados autofirmados o para diagnósticos puntuales.

Tiempos de espera

mikrotik.connection_timeout Opcional

Env: MIKROTIK_CONN_TIMEOUT · Por defecto: 10s

Tiempo máximo para conectar e iniciar sesión en la API, al arrancar y en cada reconexión; 0 significa sin límite. Usa el formato de duración de Go.

mikrotik.command_timeout Opcional

Env: MIKROTIK_CMD_TIMEOUT · Por defecto: 30s

Tiempo máximo de espera al router mientras responde a un comando de la API: hasta que empieza la respuesta, y entre dos partes de una respuesta larga. Un router que deja de responder hace fallar el comando; una respuesta que sigue llegando, como una address-list grande en un router lento, no se corta. Auméntalo si tu router tarda en empezar a responder.

Consejo

El límite vuelve a empezar con cada parte de una respuesta, así que no crece con la lista. El comando más largo es la lectura de la address-list al principio de cada pasada, que escala con cuántas entradas guarda el router (~1,8 s para 22.332 entradas en un RB5009), pero sus entradas llegan una tras otra; un bloque masivo tarda unos 130 ms.

Súbelo si ves errores de tiempo de espera en un dispositivo lento. Ambos tiempos de espera deben ser >= 0; 0 significa sin límite, y un valor negativo se rechaza al arrancar.

Pool de conexiones

mikrotik.pool_size Opcional

Env: MIKROTIK_POOL_SIZE · Por defecto: 4

Número de sesiones de la API de RouterOS que el bouncer puede usar para el trabajo en paralelo, como las eliminaciones de la reconciliación. Un valor más alto aumenta el rendimiento cuando la reconciliación tiene que borrar muchas entradas obsoletas del address-list, y con bulk_add_method: api también cuando tiene muchas que añadir por un enlace con latencia; en la LAN del router una sola sesión añade más rápido, y cada sesión extra ocupa unos 1,7 MiB de RAM del router. Las decisiones en vivo siempre usan la conexión principal, así que no se ven afectadas.

• Rango válido: 1–20
• Limitación automática: al arrancar, el bouncer consulta el límite max-sessions del servicio API del router y reduce automáticamente el tamaño efectivo del pool para que nunca supere max-sessions − 2 (reservando conexiones para el cliente principal y herramientas externas como WinBox).

mikrotik:
  pool_size: 8 # Mayor paralelismo para las eliminaciones de la reconciliación

Comprobar el límite del router

El servicio API de RouterOS tiene un ajuste max-sessions que limita las conexiones simultáneas. El valor de fábrica es 20.

# Comprobar el límite actual
/ip/service/print where name=api

# Aumentarlo (el valor máximo admitido es 1000)
/ip/service/set api max-sessions=1000

Ajuste de rendimiento

Para despliegues pequeños y medianos (≤ 5.000 IPs), el valor por defecto pool_size: 4 es óptimo. Para listas de CAPI muy grandes (más de 20.000 IPs), aumentarlo a 6–8 puede reducir notablemente el tiempo de reconciliación. Verifica siempre primero el max-sessions del router:

/ip/service/set api max-sessions=1000

Nota

Cada conexión del pool es una sesión completa de la API de RouterOS. En routers con recursos limitados (p. ej., hAP lite), mantén pool_size bajo (1–2) para evitar presión de memoria.

Método de adición masiva

mikrotik.bulk_add_method Opcional

Env: MIKROTIK_BULK_ADD_METHOD · Por defecto: script

Cómo añade la reconciliación (al arrancar y cada crowdsec.reconciliation_interval) las entradas del address-list que le faltan al router. Las decisiones en vivo no se ven afectadas: siempre se añaden con una llamada a la API cada una.

• script (por defecto): el bouncer envía hasta 100 adiciones como un único script de RouterOS. En RouterOS 7.8rc1 y posteriores es una sola llamada a /execute que ejecuta el script de forma síncrona: no se guarda nada en el router y nada llega a su log. En versiones anteriores, y para un bloque que /execute no puede ejecutar (por encima de su límite de 64 kB, o en un router que resulta no tenerlo), el bouncer crea un /system/script temporal, lo ejecuta y lo vuelve a eliminar. En ambos casos los viajes de ida y vuelta que cuesta un bloque no dependen de cuántas entradas tenga: uno mediante /execute y cuatro como script guardado. Por eso la latencia hasta el router pesa mucho menos que con api, que paga un viaje por entrada. Una adición que el script no puede hacer se notifica mediante /execute y se reintenta con su propia llamada a la API; si un script falla, ese bloque se reintenta con una llamada por entrada.
• api: cada entrada se añade con su propia llamada a la API, y las llamadas se reparten entre las conexiones del pool (pool_size), o van una tras otra por la conexión principal cuando el pool no se pudo abrir. Nunca se crea un script, y la configuración del router no se toca.

En RouterOS anterior a 7.8rc1, RouterOS registra cada script guardado con su código completo al crearlo, una auditoría de /system/script muestra los scripts del bouncer apareciendo y desapareciendo, y cada alta y baja es un cambio de configuración que RouterOS guarda; api evita todo eso. A partir de 7.8rc1, script tampoco deja nada de eso, siempre que /execute ejecute el bloque; la vuelta al script guardado descrita arriba sí lo deja. api sigue sin ejecutar ningún script, y guarda en caché el id de cada entrada que añade, así que un unban en vivo justo después de una pasada de reconciliación elimina la entrada sin buscarla antes. Las entradas del address-list con timeout, que es en lo que se convierten las decisiones, son dinámicas y se quedan en memoria en ambos casos.

mikrotik:
  bulk_add_method: api
  pool_size: 4 # las adiciones se reparten por el pool: ayuda con un enlace con latencia, no en la LAN del router

Consejo

Medido en un RB5009 (RouterOS 7.24.4), cargando unas 24.400 decisiones al arrancar:

• En la LAN del router (0,2 ms), script mediante /execute tardó unos 21 s y api con pool_size: 1 unos 23 s, ambos con aproximadamente la mitad de CPU del router que un script guardado, que tardó unos 36 s. Con el pool_size: 4 por defecto, api tardó lo mismo que un script guardado, porque aquí las sesiones extra solo compiten entre sí. Una pasada que añade unas pocas entradas tarda milisegundos con cualquiera de los dos.
• Con un enlace con latencia, cada adición por la API paga un viaje de ida y vuelta, mientras que un script paga uno por cada 100 entradas mediante /execute y cuatro como script guardado. A 36 ms, script tardó unos 33 s mediante /execute, 70 s como script guardado, y api 76 s con pool_size: 16; a 33 ms había tardado 3,7 min con 4 y 13 min con 1.

Las decisiones en vivo se aplican en cuanto llegan, también mientras corre una reconciliación: solo un comando que ya está en curso en la conexión principal, como la lectura de la address-list al principio de una pasada, retiene una hasta que termina, y un desbaneo de una dirección que la pasada en curso ya tenía previsto añadir se aplica cuando termina la pasada. Un apagado detiene una pasada en curso: la lectura de la address-list del principio, sus adiciones y sus eliminaciones. El siguiente arranque la completa.

CPU del router

mikrotik.cpu_limit Opcional

Env: MIKROTIK_CPU_LIMIT · Por defecto: 80

La carga de CPU del router, en porcentaje de todos sus núcleos, a partir de la cual el bouncer baja el ritmo de sus reconciliaciones. Mientras la carga está en ese valor o por encima, el bouncer hace una pausa antes de cada bloque de trabajo (un script de 100 altas, 100 altas o bajas sueltas, una búsqueda de duplicados) y usa una sola conexión de la API cada vez. La pausa empieza en 200 ms, se duplica por cada segundo ocupado hasta 5 s y se reduce a la mitad por cada segundo en que la carga está 10 puntos por debajo del límite (o por debajo de la mitad del límite, si es más bajo), hasta volver a pleno ritmo. Una pasada periódica también espera hasta un minuto a que baje la carga antes de leer la address-list. Los baneos y desbaneos en vivo no se frenan nunca, y se aplican mientras corre una pasada, frenada o no, salvo un desbaneo de una dirección que la pasada ya tenía previsto añadir, que se aplica cuando termina la pasada. Tampoco se frena el apagado. 0 lo desactiva.

La carga es el propio cpu-load de RouterOS: la media de todos los núcleos durante el último segundo, leída como mucho una vez por segundo mientras hay trabajo masivo. Un solo segundo ocupado, como las tareas periódicas del propio router, no frena nada: hacen falta dos seguidos.

mikrotik:
  cpu_limit: 80

Nota

Al ritmo más lento, una reconciliación añade unas 20 entradas por segundo: la lista comunitaria de 17.000 entradas tarda entonces unos 14 minutos en lugar de 14 segundos, pero sigue avanzando. En un RB5009 el método por script por defecto se queda en torno al 30 % de la CPU, así que el 80 por defecto nunca lo frena.