Как известно, использование авторизации абонентов по протоколу RADIUS в сети оператора предоставляет немало возможностей, среди которых стоит отметить Hotspot в WiFi сетях, тарифы с учетом потребляемого трафика, accounting, авторизация доступа в Интернет, разные дополнительные опции, облегчающие жизнь как абоненту, так и оператору связи. При этом множество опций просто невозможно реализовать без RADIUS.
Но бывает и так, что RADIUS задействован только потому, что о других методах авторизации оператор просто не слышал или не рискнул использовать что-то еще взамен распространенного протокола. В таких сетях все достоинства RADIUS легко перечеркиваются слишком сложными методами резервирования сервера авторизации или полным отсутствием таких методов, и внеплановое отключение или поломка биллинга приводит к массовому отключению доступа в Интернет, хотя при этом все сетевое оборудование работает исправно.
В этой статье описан один из способов работы оператора связи без использования авторизации по протоколу RADIUS на маршрутизаторах с операционной системой RouterOS (MikroTik). Плановое или внеплановое отключение биллинга никак не сказывается на абонентах – они продолжают работать как ни в чем не бывало. Конечно, если у вас DNS не на сервере биллинга!
В качестве биллинга используется LanBilling 2.0 – в нем реализована неплохая поддержка событий включения, отключения, редактирования, создания и удаления абонентов. На эту роль с доработками подойдет любая система с похожим механизмом событий.
Все взаимодействие с RouterOS происходит через API. Для начала на маршрутизаторе нужно создать выделенного пользователя, под которым будет осуществляться удаленное управление, с такими реквизитами доступа:
Далее необходимо настроить Firewall. Он будет выполнять бо́льшую часть работы, связанной с блокировкой абонентов, переадресацией на "попрошайку" и т.д.
# Полный доступ к избранным ресурсам
/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 firewall filter add action=reject chain=forward \
out-interface=ether-wan \
reject-with=icmp-admin-prohibited \
src-address-list=blocked
# Транслируем все серые адреса
/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
Теперь маршрутизатор готов выполнять основные функции по обслуживанию доступа абонентов в Интернет без RADIUS. Скорость по тарифу ограничивается в /queue simple – этим занимается биллинг (Раздел "Подготовка биллинга"). Неплательщики блокируются и уведомляются о блокировке с помощью переадресации на "попрошайку", но при этом имеют доступ к избранным внешним ресурсам.
Дополнительно, если в этом есть необходимость, можно активировать PPPoE/PPTP/L2TP службу – с биллинга поступают команды создания учетных записей в разделе /ppp secret. Все вышеописанное будет работать с туннельными протоколами без доработок, что увеличивает гибкость решения.
Подготовка биллинга, в данном случае это будет Lanbilling, заключается в написании скриптов обработки событий включения, отключения, создания, удаления и редактирования учетной записи абонента. Дополнительно нужно убедиться, что учетными записями занимается именно агент LBarcd.
Для начала биллингу нужно указать, для каких событий, какие скрипты используются. Эти параметры указываются в конфигурационном файле /etc/billing.conf.LBarcd. Конфигурационный файл относится к RADIUS-агенту LBarcd, от которого в данном случае требуется только регистрация событий и исполнение сценария, привязанного к событию. Каждый скрипт вызывается с определенным набором параметров, для каждого скрипта набор один и тот же:
Конфигурационный файл событий агента можно скачать с репозитария на 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 абонентов и вы ищете простое надежное решение по контролю доступа в Интернет, то описанный в статье вариант может стать отличным выбором.
Репозиторий с исходным кодом.
Документация на Ланбиллинг.
Материал:
В этой статье описан один из способов работы оператора связи без использования авторизации по протоколу RADIUS на маршрутизаторах с операционной системой RouterOS (MikroTik). Плановое или внеплановое отключение биллинга никак не сказывается на абонентах – они продолжают работать как ни в чем не бывало.
Полный текст
Нету
Есть. Статья описывает реального оператора =)
Ага, а ФСБ, будет ручками проверять авторизован ли абонент?
Все абоненты в биллинге авторизованы. Так сойдет?
Сколько раз мы делали взаимодействие → им надо было Radius+Neflow+зеркало всего трафика и ИС по абонентам. Без вариантов.
Очевидно, для вас эта схема работы не подходит. Но это не значит, что она не подходит никому :)
Для примера - небольшой оператор берет несколько внешних адресов у аплинка, арендует у него канал. Аплинк решает все вопросы с сормом и т.д.. Маленькому оператору RADIUS в данном случае не нужен.
В чем сложность резервирования? Поднять еще один RADIUS сервер это сложность? Вменяемое оборудование по таймауту переключается на другой сервер. В своей практике ни разу не встречал оборудования или софта, где можно было бы указать только один единственный адрес RADIUSа.
У нас на базе FreeRADIUS + rlm_perl работают: AAA, DHCP, 802.1x. Все отлично резервируется и никаких проблем при отключении одного из серверов на обслуживание, нет.
Похоже создатель статьи тоже многое не слышал=) хотя сам обвиняет некоторых в использовании радиуса, указывая что они о других способах не слышали=)
Микротик может сам пускать абонентов в интернет на определенное время (например 10 минут) с интервалом в заданное время (например 1 час), по событию доступа на определенный IP адрес и порт - например адрес личного кабинета. При этом никакие "особенные" возможности биллинга не нужны.
Сама же авторизация по радиусу хороша в случаях, когда есть некий центр сети, и много удаленных узлов, которые могут иметь и свои каналы интернета и т.п., централизованно ведется база абонентов. При этом заранее не известно где абонент будет авторизован. Тут да, радиус удобен. Если же используется единый узел, весь трафик абонентов проходит через него, то статическая авторизация намного удобнее и надежнее, т.к. при не доступности биллинга абоненты смогут и дальше работать, и вновь авторизовываться. Что позволяет исключить много проблем с биллингом, когда после обновления что-то пошло не так.
Никого ни разу не обвиняю. Всегда есть свои нюансы, кому-то этот способ подойдет, кому-то нет. Про событие доступа интересная идея, спасибо.