Tutorial
PPPoE-сервер MikroTik для провайдерів
Як налаштувати PPPoE-сервер MikroTik для провайдера: пули IP, профілі PPP, secrets, rate limits та віддалене керування абонентами за CGNAT.
Стисло PPPoE-сервер MikroTik дає змогу провайдеру автентифікувати абонентів, видавати кожному IP-адресу та застосовувати обмеження швидкості за тарифом — усе з RouterOS, без зовнішнього RADIUS для невеликих розгортань. Налаштування — це коротка впорядкована послідовність: пул IP, профіль PPP, secrets абонентів, служба PPPoE та NAT. Складніша задача — не налаштувати один концентратор, а запустити узгоджену, перевірювану конфігурацію на багатьох із них — часто за CGNAT. Цей посібник охоплює обидва випадки.
Що Таке PPPoE-сервер MikroTik?
PPPoE-сервер MikroTik — це служба RouterOS, яка автентифікує кожного абонента через Point-to-Point Protocol over Ethernet, видає йому IP з пулу та застосовує профіль, що керує його шлюзом, DNS і обмеженням швидкості. Саме так більшість малих і середніх провайдерів керують клієнтськими підключеннями: клієнт під’єднується з іменем користувача та паролем, сервер перевіряє облікові дані, і сесія успадковує призначений тариф — автентифікація за користувачем, призначення IP і контроль смуги без окремого обладнання (Документація MikroTik — PPPoE).
PPPoE залишається стандартом провайдерів через підзвітність. Кожен абонент має власні облікові дані, тож ви можете вимкнути обліковий запис за несплату, бачити, хто онлайн, і прив’язати до людини фіксовану адресу чи швидкість — нічого з цього доставка через bridge або DHCP не дає чисто. Уся конфігурація зводиться до однієї ідеї: задайте тариф один раз у профілі, а потім приєднайте до нього абонентів.
Крок 1 — Створіть пул IP
Почніть з адрес, які RouterOS позичатиме абонентам. Пул — це іменований блок, наприклад /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254, розрахований на одночасні сесії, які нестиме цей концентратор, із запасом. Тримайте адресу шлюзу профілю (тобто local-address) поза діапазоном, що видається, щоб вона ніколи випадково не дісталася клієнту.
Підбирайте розмір пулу під обладнання — скромний роутер тягне сотні сесій, пристрій класу CCR — тисячі (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). Щоб натомість роздавати публічні IP, спрямуйте пул на ваш маршрутизовний блок і пропустіть NAT на Кроці 5.
Крок 2 — Побудуйте профіль PPP
Профіль PPP — це місце, де живе тариф. Він задає local-address (шлюз, який бачить кожен абонент), пул remote-address із Кроку 1, сервери DNS і — найважливіше для провайдера — rate-limit, що обмежує кожну сесію. Призначте профіль абоненту, і він успадкує швидкість, тож тариф «20/10» — це один профіль, повторно використаний на тисячах облікових записів (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).
Одна деталь підводить майже всіх: напрямок. RouterOS читає rate-limit профілю як rx-rate/tx-rate з погляду сервера — спочатку віддача абонента, потім прийом, навпаки до того, як клієнти описують свій тариф. Пакет «100 Мбіт/с на прийом / 30 Мбіт/с на віддачу» записується як rate-limit=30M/100M. Переплутайте — і кожен клієнт тихо отримає перевернутий тариф — саме ту помилку в масштабі парку, яку запобігає шаблонна конфігурація.
Крок 3 — Додайте secrets абонентів
Кожному абоненту потрібен «secret» — ім’я користувача, пароль і профіль, що визначає його тариф, створюється в /ppp secret. Для невеликої бази це і є вся база користувачів: додайте по secret на клієнта, за бажання закріпіть фіксований remote-address для статичного IP і вимкніть secret, щоб припинити обслуговування. Це та сама підзвітність за обліковими даними, яку User Manager MikroTik розширює для абонентів hotspot, описана в нашому посібнику про шлюз hotspot 10.5.50.1 та User Manager.
Локальні secrets перестають масштабуватися в діапазоні від сотень до тисяч, де правка одного роутера на кожну зміну клієнта стає вузьким місцем. У цей момент ви переносите автентифікацію на зовнішній сервер RADIUS, і концентратори просто запитують RADIUS, чи дійсний логін — зберігаючи базу абонентів в одному місці.
Крок 4 — Увімкніть PPPoE-сервер на інтерфейсі доступу
Тепер увімкніть службу. Додайте PPPoE-сервер командою /interface pppoe-server server, прив’яжіть його до інтерфейсу, зверненого до вашої мережі доступу (порт, VLAN або bridge), задайте його default-profile на профіль із Кроку 2 і виберіть методи автентифікації — pap, chap або mschap2. RouterOS тоді відповідає на виявлення PPPoE на цьому інтерфейсі та автентифікує будь-якого клієнта, що під’єднується з дійсним secret.
Два налаштування важливі при масштабуванні. Опція one-session-per-host не дає абоненту відкривати кілька одночасних сесій, а max-mtu/max-mru слід задати так, щоб накладні витрати PPPoE не фрагментували клієнтський трафік. Там, де мережа доступу сегментована за клієнтом або зоною, наш посібник з налаштування bridge MikroTik охоплює основу Layer 2, на яку спирається сервер.
Крок 5 — Додайте правила NAT і фаервола
Якщо на Кроці 1 ви видали абонентам приватні адреси, їхньому трафіку потрібна трансляція. Додайте правило masquerade у ланцюжку srcnat, прив’язане до вашого вихідного інтерфейсу WAN, щоб кожна сесія PPPoE досягала інтернету — ті самі основи NAT, що описані в нашому посібнику з налаштування NAT на MikroTik. Якщо ви роздали публічні IP, пропустіть masquerade і маршрутизуйте блок.
Потім захистіть концентратор. Служба PPPoE має бути доступною абонентам, а інтерфейси керування роутера — ні, тож додайте правила фаервола, що відкидають доступ Winbox, API та WebFig з боку, зверненого до абонента. Концентратор, що несе реальний дохід від клієнтів, — саме той пристрій, який ви не хочете робити доступним із перехопленої сесії.
Крок 6 — Віддалено керуйте парком і перевіряйте його
Ось частина, яку пропускають посібники про один роутер. Підняти PPPoE на одному пристрої легко; запустити однакові профілі, налаштування MTU та правила фаервола на десятках концентраторів — і довести, що кожен автентифікує сесії та застосовує правильні rate limits — це і є справжня задача провайдера. Вона ускладнюється, коли роутер доступу стоїть за Carrier-Grade NAT без публічного IP, що дедалі частіше трапляється, оскільки оператори спираються на аплінки LTE та Starlink.
Ось де централізоване керування виправдовує себе: MKController тримає кожен роутер доступним через автентифікований вихідний тунель навіть тоді, коли в нього немає публічної адреси — той самий підхід, що в нашому посібнику з віддаленого доступу MikroTik за CGNAT — тож ви перевіряєте конфігурацію та накочуєте виправлення на весь парк, із телеметрією, яка позначає пристрій зі скинутими сесіями ще до дзвінка клієнтів.
Поради
- Шаблонізуйте профіль, а не secrets — кожна зміна тарифу має торкатися одного профілю, а не тисяч облікових записів.
- Стежте за CPU концентратора: черги на сесію з
rate-limitнакопичуються, і перевантажений пристрій тихо скидає сесії. - Задавайте
max-mtu/max-mruсвідомо. PPPoE додає 8 байт накладних витрат, і фрагментація, що виникає, — прихована причина більшості звернень «на одному майданчику повільно». - Централізуйте автентифікацію після кількох сотень користувачів — локальні secrets, розкидані по роутерах, стає неможливо аудіювати.
Керуйте всім краєм PPPoE з одного екрана
PPPoE-сервер на одному MikroTik — це легко. Запустити його на парку провайдера — однакові профілі, правильний напрямок rate-limit на кожному пристрої, заблоковане керування та доказ, що кожен концентратор автентифікує навіть за CGNAT без публічного IP — ось де оператори втрачають цілі дні. Саме для цього створено MKController: дотягнутися до кожного роутера через захищений вихідний тунель, перевірити конфігурацію, спостерігати за живими сесіями та накотити виправлення одразу на весь парк, із телеметрією, яка позначає пристрій зі скинутими сесіями ще до того, як клієнт зателефонує. Так провайдери, що запускають PPPoE на MikroTik, перетворюють рутину «роутер за роутером» на єдину площину керування.