vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

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

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

Как известно, использование авторизации абонентов по протоколу 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

Комментарии:(9) комментировать

30 мая 2017 - 17:21
Robot_NagNews:
#1

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

Полный текст


30 мая 2017 - 17:21
Diman_xxxx:
#2

Нету


30 мая 2017 - 17:37
infery:
#3

Просмотр сообщенияDiman_xxxx (30 мая 2017 - 16:21) писал:

Нету


Есть. Статья описывает реального оператора =)


30 мая 2017 - 19:30
saaremaa:
#4

Ага, а ФСБ, будет ручками проверять авторизован ли абонент?


30 мая 2017 - 19:43
infery:
#5

Просмотр сообщенияsaaremaa (30 мая 2017 - 18:30) писал:

Ага, а ФСБ, будет ручками проверять авторизован ли абонент?


Все абоненты в биллинге авторизованы. Так сойдет?


30 мая 2017 - 19:47
saaremaa:
#6

Сколько раз мы делали взаимодействие → им надо было Radius+Neflow+зеркало всего трафика и ИС по абонентам. Без вариантов.


30 мая 2017 - 19:57
infery:
#7

Просмотр сообщенияsaaremaa (30 мая 2017 - 18:47) писал:

Сколько раз мы делали взаимодействие → им надо было Radius+Neflow+зеркало всего трафика.


Очевидно, для вас эта схема работы не подходит. Но это не значит, что она не подходит никому :)
Для примера - небольшой оператор берет несколько внешних адресов у аплинка, арендует у него канал. Аплинк решает все вопросы с сормом и т.д.. Маленькому оператору RADIUS в данном случае не нужен.


30 мая 2017 - 20:32
SokolovS:
#8

Цитата

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


В чем сложность резервирования? Поднять еще один RADIUS сервер это сложность? Вменяемое оборудование по таймауту переключается на другой сервер. В своей практике ни разу не встречал оборудования или софта, где можно было бы указать только один единственный адрес RADIUSа.
У нас на базе FreeRADIUS + rlm_perl работают: AAA, DHCP, 802.1x. Все отлично резервируется и никаких проблем при отключении одного из серверов на обслуживание, нет.


1 июня 2017 - 13:34
Saab95:
#9

Похоже создатель статьи тоже многое не слышал=) хотя сам обвиняет некоторых в использовании радиуса, указывая что они о других способах не слышали=)

Микротик может сам пускать абонентов в интернет на определенное время (например 10 минут) с интервалом в заданное время (например 1 час), по событию доступа на определенный IP адрес и порт - например адрес личного кабинета. При этом никакие "особенные" возможности биллинга не нужны.

Сама же авторизация по радиусу хороша в случаях, когда есть некий центр сети, и много удаленных узлов, которые могут иметь и свои каналы интернета и т.п., централизованно ведется база абонентов. При этом заранее не известно где абонент будет авторизован. Тут да, радиус удобен. Если же используется единый узел, весь трафик абонентов проходит через него, то статическая авторизация намного удобнее и надежнее, т.к. при не доступности биллинга абоненты смогут и дальше работать, и вновь авторизовываться. Что позволяет исключить много проблем с биллингом, когда после обновления что-то пошло не так.


1 июня 2017 - 13:44
infery:
#10

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


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

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

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