Servidor PPPoE MikroTik para ISPs

Resumen Un servidor PPPoE MikroTik permite a un ISP autenticar abonados, asignar a cada uno una dirección IP e imponer un límite de velocidad por plan — todo desde RouterOS, sin RADIUS externo en implantaciones pequeñas. La configuración es una cadena corta y ordenada: un pool de IP, un perfil PPP, los secrets de abonado, el servicio PPPoE y el NAT. El problema más difícil no es configurar un concentrador, sino ejecutar una configuración consistente y verificable en muchos de ellos — a menudo tras CGNAT. Esta guía cubre ambos.

¿Qué Es un Servidor PPPoE MikroTik?

Un servidor PPPoE MikroTik es un servicio de RouterOS que autentica a cada abonado sobre Point-to-Point Protocol over Ethernet, le entrega una IP de un pool y aplica un perfil que controla su gateway, DNS y límite de velocidad. Así es como la mayoría de los ISP pequeños y medianos gestionan las conexiones de clientes: un cliente marca con usuario y contraseña, el servidor verifica la credencial y la sesión hereda el plan asignado — autenticación por usuario, asignación de IP y control de ancho de banda sin equipo aparte (Documentación de MikroTik — PPPoE).

El PPPoE sigue siendo el estándar de los ISP por la rendición de cuentas. Cada abonado tiene una credencial individual, así que puedes desactivar una cuenta por impago, ver quién está en línea y vincular una dirección fija o una velocidad a una persona — nada de lo cual la entrega por bridge o DHCP ofrece de forma limpia. Toda la configuración se reduce a una idea: define el plan una vez en un perfil y luego conecta a él a los abonados.

Paso 1 — Crea el pool de IP

Empieza por las direcciones que RouterOS prestará a los abonados. Un pool es un bloque con nombre — por ejemplo /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — dimensionado a las sesiones simultáneas que llevará este concentrador, con margen. Mantén la dirección de gateway del perfil (el local-address) fuera del rango prestable para que nunca se entregue a un cliente por accidente.

Dimensiona el pool según el hardware — un router modesto maneja cientos de sesiones, un equipo clase CCR los miles (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). Para entregar IPs públicas, apunta el pool a tu bloque enrutable y omite el NAT del Paso 5.

Paso 2 — Construye el perfil PPP

El perfil PPP es donde vive el plan. Define el local-address (el gateway que ve cada abonado), el pool de remote-address del Paso 1, los servidores DNS y — lo más importante para un ISP — el rate-limit que limita cada sesión. Asigna el perfil a un abonado y hereda la velocidad, así que un plan “20/10” es un perfil reutilizado en miles de cuentas (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).

Un detalle atrapa a casi todos: la dirección. RouterOS lee el rate-limit del perfil como rx-rate/tx-rate desde el punto de vista del servidor — primero la subida del abonado, después la bajada, al revés de cómo los clientes describen su plan. Un paquete de “100 Mbps de bajada / 30 Mbps de subida” se escribe rate-limit=30M/100M. Inviértelo y cada cliente recibe en silencio un plan cambiado — justo el error a escala de flota que la configuración con plantilla evita.

Paso 3 — Añade los secrets de abonado

Cada abonado necesita un “secret” — usuario, contraseña y el perfil que define su plan, creado en /ppp secret. Para una base pequeña, esto es toda la base de usuarios: añade un secret por cliente, opcionalmente fija un remote-address para una IP estática y desactiva el secret para cortar el servicio. Es la misma rendición de cuentas por credencial que el User Manager de MikroTik extiende a los abonados de hotspot, tratada en nuestra guía sobre el gateway de hotspot 10.5.50.1 y el User Manager.

Los secrets locales dejan de escalar en el rango de cientos a miles, donde editar un router por cada cambio de cliente se vuelve el cuello de botella. En ese punto trasladas la autenticación a un servidor RADIUS externo, y los concentradores simplemente preguntan a RADIUS si un login es válido — manteniendo la base de abonados en un solo lugar.

Paso 4 — Activa el servidor PPPoE en la interfaz de acceso

Ahora enciende el servicio. Añade un servidor PPPoE con /interface pppoe-server server, vincúlalo a la interfaz orientada a tu red de acceso (un puerto, VLAN o bridge), define su default-profile con el perfil del Paso 2 y elige los métodos de autenticación — pap, chap o mschap2. RouterOS entonces responde al descubrimiento PPPoE en esa interfaz y autentica a cualquier cliente que marque con un secret válido.

Dos ajustes importan a escala. La opción one-session-per-host impide que un abonado abra varias sesiones simultáneas, y max-mtu/max-mru deben fijarse para que el overhead del PPPoE no fragmente el tráfico del cliente. Donde la red de acceso está segmentada por cliente o zona, nuestra guía de configuración de bridge MikroTik cubre la base de Capa 2 sobre la que se apoya el servidor.

Paso 5 — Añade reglas de NAT y firewall

Si asignaste direcciones privadas a los abonados en el Paso 1, su tráfico necesita traducción. Añade una regla de masquerade en la cadena srcnat vinculada a tu interfaz de salida WAN para que cada sesión PPPoE alcance internet — los mismos fundamentos de NAT tratados en nuestra guía para configurar NAT en MikroTik. Si entregaste IPs públicas, omite el masquerade y enruta el bloque.

Luego protege el concentrador. El servicio PPPoE debe ser alcanzable por los abonados, pero las interfaces de gestión del router no, así que añade reglas de firewall que descarten el acceso a Winbox, API y WebFig desde el lado orientado al abonado. Un concentrador que carga ingresos reales de clientes es justo el dispositivo que no quieres alcanzable desde una sesión secuestrada.

Paso 6 — Gestiona y verifica la flota de forma remota

Aquí está la parte que los tutoriales de un solo router omiten. Levantar PPPoE en una caja es fácil; ejecutar perfiles, ajustes de MTU y reglas de firewall idénticos en docenas de concentradores — y probar que cada uno autentica sesiones e impone los rate limits correctos — es el verdadero problema del ISP. Se complica cuando un router de acceso está tras Carrier-Grade NAT sin IP pública, algo cada vez más común a medida que los operadores se apoyan en enlaces LTE y Starlink.

Aquí es donde la gestión centralizada gana su lugar: MKController mantiene cada router alcanzable a través de un túnel saliente autenticado incluso cuando no tiene dirección pública — el mismo enfoque de nuestra guía de acceso remoto MikroTik tras CGNAT — para que audites la configuración y apliques correcciones a toda la flota, con telemetría que señala una caja con sesiones caídas antes de que los clientes llamen.

Consejos

• Plantilla el perfil, no los secrets — cada cambio de plan debería tocar un perfil, nunca miles de cuentas.
• Vigila la CPU del concentrador: las colas por sesión del rate-limit se acumulan, y una caja sobrecargada descarta sesiones en silencio.
• Define max-mtu/max-mru con cuidado. El PPPoE añade 8 bytes de overhead, y la fragmentación resultante es la causa oculta de la mayoría de los tickets de “va lento en un sitio”.
• Centraliza la autenticación más allá de unos cientos de usuarios — los secrets locales dispersos por los routers se vuelven imposibles de auditar.

Gestiona todo tu borde PPPoE desde una sola pantalla

Un servidor PPPoE en un solo MikroTik es fácil. Ejecutarlo en una flota de ISP — perfiles idénticos, la dirección del rate-limit correcta en cada caja, la gestión bloqueada y la prueba de que cada concentrador autentica incluso tras CGNAT sin IP pública — es donde los operadores pierden tardes enteras. Ese es el trabajo para el que se creó MKController: alcanzar cada router por un túnel saliente seguro, auditar la configuración, observar sesiones en vivo y aplicar una corrección a toda la flota a la vez, con telemetría que señala una caja con sesiones caídas antes de que un cliente siquiera llame. Así es como los ISP que ejecutan PPPoE en MikroTik convierten una tarea router por router en un único plano de control.

Comienza tu prueba gratuita de MKController