Альтернатива Radius для небольших сетей
Известно, что авторизация абонентов по протоколу 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 тысяч абонентов, то этот способ станет наиболее подходящим.
Подготовил Артём Деулин
