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, превращают рутину «роутер за роутером» в единую плоскость управления.