Известно, что авторизация абонентов по протоколу RADIUS в сети оператора дает массу возможностей — это тарифы с учетом трафика, возможность организации авторизации при доступе к сети, Hotspot в сетях Wi-Fi и большое количество других вещей, которые сложно реализовать без RADIUS.

Нередко операторы используют RADIUS лишь потому, что им попросту неизвестно о других способах авторизации или не рискуют использовать что-то иное кроме распространенного протокола. В таких случаях все достоинства RADIUS сходят на нет из-за сложных методов резервирования сервера или их отсутствие. Неожиданное же отключение биллинга приводит к отключению интернета у абонентов при исправной работе сетевого оборудования.

Поэтому хотелось бы рассказать о том, как оператор связи может избежать авторизации по протоколу RADIUS на маршрутизаторах с операционной системой RouterOS (MikroTik). В качестве биллинга возьмем LanBilling 2.0, где реализована поддержка событий включения, отключения, редактирования, создания и удаления абонентов. На эту роль с доработками подойдет любая система с похожим механизмом событий.

Взаимодействие с RouterOS происходит через API. Первым делом на маршрутизаторе необходимо создать выделенного пользователя, который и осуществит удаленное управление.

Реквизиты доступа будут такие:
Логин: api
Пароль: api
Доступ только с сервера биллинга: 192.0.2.2


Следующим шагом настраиваем файрвол, который будет выполнять весомую часть работы по блокировке абонентов и переадресации. Для этого необходимо разрешить всем абонентам использовать избранные ресурсы (внешний DNS-сервер, сайт компании).

# Полный доступ к избранным ресурсам
/ip firewall filter add chain=forward \
dst-address-list=permited-destinations \
out-interface=ether-wan
В дальнейшем используем address-list permited-destinations. В него при надобности будут добавляться адреса, а правила файрвола останутся прежними.
Далее нужно разрешить абонентам посещать ресурсы для оплаты услуг. Механизм, прописанный ниже, обеспечит абонентам доступ ко всем нужным для оплаты ресурсам.
# Блокировка популярных ресурсов, ненужных для оплаты
/ip firewall layer7-protocol add name=social-networks \
regexp=vk.com|mail.ru|ok.ru
# Пропускаем абонентов в процессе оплаты на https-ресурсы
/ip firewall filter add chain=forward \
dst-port=443 \
layer7-protocol=!social-networks \
out-interface=ether-wan \
protocol=tcp \
src-address-list=payers-list
Далее блокируем доступ в интернет не оплатившим услугу. В момент блокировки биллинг добавляет IP абонента в address-list blocked.
# Блокировка неплательщиков
/ip firewall filter add action=reject chain=forward \
out-interface=ether-wan \
reject-with=icmp-admin-prohibited \
src-address-list=blocked

Далее настраиваем NAT. Это необходимо для переадресации абонентов на страницу с уведомлением о блокировке и трансляции адресов абонентов для выхода в интернет.

# Транслируем все серые адреса
/ip firewall nat add action=same chain=srcnat \
out-interface=ether-wan same-not-by-dst=yes \
src-address-list=nat-all-abonents \
to-addresses=203.0.113.0/26
# Не переадресовываем на попрошайку тех, кто в процессе оплаты
/ip firewall nat add action=accept chain=dstnat \
src-address-list=payers-list
# Переадресовываем на попрошайку(192.0.2.3) всех остальных
# неплательщиков, не забывая про избранные ресурсы
/ip firewall nat add action=dst-nat chain=dstnat \
dst-address-list=!permited-destinations \
protocol=tcp src-address-list=blocked \
to-addresses=192.0.2.3 to-ports=80

Перечисленных выше правил в цепочке forward достаточно для предоставления доступа в интернет. Чтобы ограничить доступ к маршрутизатору и обеспечить дополнительную безопасность можно добавить несколько правил в цепочку input

После этих манипуляций маршрутизатор может выполнять основные функции по доступу абонентов в сеть без помощи RADIUS. Скорость по тарифу ограничивается в /queue simple этим занимается биллинг. Неплательщики автоматически блокируются, а их запросы переадресовывается на сайт-напоминание. При этом доступ к внешним избранным ресурсам (сервисы оплаты) должники все же имеют.

Подготавливаем биллинг

Подготовка биллинга подразумевает написание скриптов обработки событий включения, отключения, создания, удаления и редактирования учетной записи абонента. В качестве примера будем использовать Lanbilling.



Дополнительно нужно убедиться, что учетными записями занимается именно агент LBarcd.



Первым делом показываем биллингу какие скрипты и для каких событий мы будем использовать. Делается это путем изменения параметров в файле /etc/billing.conf.LBarcd.

Каждый скрипт вызывается с определенным набором параметров, для каждого скрипта набор один и тот же:

login (имя пользователя в учетной записи)
password (пароль пользователя в учетной записи)
segment (IP-адрес учетной записи)
netmask (Маска для IP-адреса в dot-decimal notation. Например, 255.255.255.255)
rate limit (Скорость тарифа для этой учетной записи в Килобитах. Например, 10240)

Конфигурационный файл событий агента можно скачать с репозитария на github.
Каждый сценарий обработки события включает библиотеку функций, которая в свою очередь использует PHP-класс для работы с RouterOS через API. Исходный код каждого сценария, библиотеки функций и класс для работы с API доступны в репозитории github.
После внесения изменений в “конфиг” систем готова к работе. Абоненты, имеющие положительный баланс на счету, спокойно пользуются услугой, а неплательщики могут пользоваться лишь локальной сетью и разрешенным сайтам.
Нередко происходит так, что у оператора возникает потребность в возможности обеспечить абоненту автоматизированное временное включение доступа, или наполнение списка разрешенных ресурсов “айпишниками” всех известных платежных систем.

Для это в исходном коде в личном кабинете абонента делается небольшая правка. Остальные функции уже настроены – address-list payers-list на MikroTik и дополнительная функция allow_payment в библиотеке functions.php.

В нашем случае прием платежей осуществляется с помощью Яндекс.Кассы, а значит правку будем вносить в файл
/usr/local/billing/phpclient/client2/client/components/payment/yandex/Payment_Yandex_Pay.php в метод обработки нажатия кнопки «Оплатить» в личном кабинете пользователя.



Необходимо вставить строку

file_get_contents(«billing.example.com/tmp_access.php?ip=». $_SERVER[«REMOTE_ADDR»]);
перед строкой
$this->post($params, $this->conf(«operatorURL»));
где billing.example.com – адрес административного веб-интерфейса Lanbilling.

Таким образом мы отправляем GET запрос нашему сценарию на биллинге, а в качестве параметра передаем IP-адрес клиента, который находится в личном кабинете и нажимает кнопку «Оплатить». Содержимое сценария tmp_access.php можно посмотреть и скачать на github. Удаленный сценарий добавляет IP-адрес абонента в payers-list c time-out 20 минут, после чего абонент без проблем переходит на любую страницу для оплаты.

Если же абонент заходит через мобильный интернет, то в список попадает “левый” адрес мобильной сети, который будет удален автоматически через 20 минут. Если же абонент заходит с адреса локальной сети оператора, то система будет работать в как прописано. Собственно, этот же скрипт можно вставить на странице с предупреждением об оплате, где размещены поле для ввода номера договора, суммы оплаты и кнопка «Оплатить».

С написанным выше можно поспорить, но стоит принять во внимание тот факт, что это решение не для крупных сетей. Собственно, как и MikroTik с RouterOS. Если же в вашей сети не более 3 тысяч абонентов, то этот способ станет наиболее подходящим.

Подготовил Артём Деулин