vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

Есть ли жизнь без RADIUS? 9

Дата публикации: 29.05.2017
Количество просмотров: 5206
Автор:

Как известно, использование авторизации абонентов по протоколу RADIUS в сети оператора предоставляет немало возможностей, среди которых стоит отметить Hotspot в WiFi сетях, тарифы с учетом потребляемого трафика, accounting, авторизация доступа в Интернет, разные дополнительные опции, облегчающие жизнь как абоненту, так и оператору связи. При этом множество опций просто невозможно реализовать без RADIUS.

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

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

В качестве биллинга используется LanBilling 2.0 – в нем реализована неплохая поддержка событий включения, отключения, редактирования, создания и удаления абонентов. На эту роль с доработками подойдет любая система с похожим механизмом событий.

 

Подготовка MikroTik RouterOS

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

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

Далее необходимо настроить Firewall. Он будет выполнять бо́льшую часть работы, связанной с блокировкой абонентов, переадресацией на "попрошайку" и т.д.

  • Самым первым правилом разрешим всем без исключения абонентам использовать избранные ресурсы. Например, это может быть внешний DNS-сервер, сайт компании или сеть партнера.

# Полный доступ к избранным ресурсам
/ip firewall filter add chain=forward \
dst-address-list=permited-destinations \
out-interface=ether-wan

Для удобства дальнейшего обслуживания используется address-list permited-destinations, в который при необходимости добавляются новые адреса, а правила в firewall остаются неизменными.

  • Следующим правилом разрешаем абонентам посещать ресурсы, необходимые для оплаты услуг. Здесь не будет списка банковских шлюзов, платежных систем и т.д. Этот механизм позволит мгновенно активировать абоненту доступ в Интернет ко всем необходимым для оплаты средств ресурсам. Часть этого механизма находится в биллинге и описана в разделе "Подготовка биллинга". Для перестраховки можно запретить социальные сети и поисковики.

# Блокировка популярных ресурсов, ненужных для оплаты
/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. Это нужно как для трансляции адресов абонентов для выхода в Интернет (SNAT), так и для переадресации абонентов на страницу уведомления о блокировке (DNAT).

# Транслируем все серые адреса
/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 – этим занимается биллинг (Раздел "Подготовка биллинга"). Неплательщики блокируются и уведомляются о блокировке с помощью переадресации на "попрошайку", но при этом имеют доступ к избранным внешним ресурсам.

Дополнительно, если в этом есть необходимость, можно активировать PPPoE/PPTP/L2TP службу – с биллинга поступают команды создания учетных записей в разделе /ppp secret. Все вышеописанное будет работать с туннельными протоколами без доработок, что увеличивает гибкость решения.

 

Подготовка биллинга

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

Для начала биллингу нужно указать, для каких событий, какие скрипты используются. Эти параметры указываются в конфигурационном файле /etc/billing.conf.LBarcd. Конфигурационный файл относится к RADIUS-агенту LBarcd, от которого в данном случае требуется только регистрация событий и исполнение сценария, привязанного к событию. Каждый скрипт вызывается с определенным набором параметров, для каждого скрипта набор один и тот же:

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


Конфигурационный файл событий агента можно скачать с репозитария на github.

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

После внесения изменений в billing.conf.LBarcd, редактирования скриптов событий и размещения необходимых файлов в нужных каталогах, система готова к работе. Абоненты, оплатившие услугу работаю в Интернете и качают файлы на тарифной скорости. Заблокированные абоненты имеют доступ только к локальной сети и разрешенным ресурсам.

 

Доступ в Интернет для оплаты

Довольно часто заблокированные абоненты просят временно активировать доступ в Интернет, чтобы оплатить услугу. Со временем возникает необходимость или автоматизации временного включения доступа, или наполнения списка разрешенных ресурсов в виде IP адресов платежных систем. Каждый оператор решает этот вопрос по-своему, но наша реализация BRAS без RADIUS позволяет решить проблему временного включения услуги, открывая доступ ко всем платежным.

Для этого необходимо сделать небольшую правку исходного кода в личном кабинете пользователя, все остальное уже настроено – 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("http://billing.example.com/tmp_access.php?ip=" . $_SERVER["REMOTE_ADDR"]);

перед строкой

$this->post($params, $this->conf("operatorURL"));

где http://billing.example.com – адрес административного веб-интерфейса Lanbilling.

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

Дополнительно в сценарии активации нужно предусмотреть случай, когда абонент злоупотребляет и часто включает доступ. Злоупотребление можно предотвратить, например, записывая каждую попытку доступа во временный файл. Этот файл удаляется раз в неделю. Вариантов на самом деле может быть великое множество, в том числе с использованием базы данных. Тут каждый реализует так, как считает нужным.

 

Заключение

Разумеется, это решение не для крупных сетей, как и сам MikroTik с RouterOS, каждый найдет плюсы и минусы для себя. Немного не хватает скрипта для синхронизации абонентской базы биллинга с маршрутизатором, этот момент остается на усмотрение оператора. Для инсталляций с большим числом абонентов в роли BRAS без RADIUS можно использовать СКАТ, об этом будет следующая статья. На СКАТ любое количество абонетских полисеров/тарифов создается в считанные секунды.

Другими словами, если у вас не более 3000 абонентов и вы ищете простое надежное решение по контролю доступа в Интернет, то описанный в статье вариант может стать отличным выбором.

 

Ссылки

Репозиторий с исходным кодом. 

Документация на Ланбиллинг.

От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/article/31680/est-li-jizn-bez-radius-.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться