Биллинг Ideco АСР + MikroTik ROS

Материал из Xgu.ru

Перейти к: навигация, поиск
Автор: White Crow

Инструкция для версии Ideco АСР 3.9.7 и MikroTik Router OS 5.22

!!!Важно!!! Похоже, что нужно отвыкать от бренда Ideco и привыкать к названию Сarbon Soft. Ибо, насколько я понимаю - произошел раскол компании, и теперь есть уже два юрлица, два разных сайта, два разных бренда - и соответственно разные продукты - вместо АСР Ideco - Carbon Billing. Но так как это не простой и долгий процесс разделения - пока еще существует именно Ideco АСР 3.9.7. Потому что Carbon Billing 5 находится в статусе Beta. (Чуть позже я "потискаю" данный продукт на предмет женитьбы его с MikroTik Router OS. И заодно потискаем новую версию MikroTik Router OS 6 - которая тоже пока в статусе beta, но обещает новые возможности и уровень производительности на свежем железе - т.к. обновилось ядро Linux и драйверы (интересно будет найти и потестить современные мощные серверные сетевые карты и свежую серверную платформу). И, возможно, сделаю отдельную инструкцию типа Carbon Billing 5 + MikroTik Router OS 6.


В статье рассматривается инсталляция и настройка связки Mikrotik и биллинговой системы Ideco ACP. Рассматриваемая в статье связка может использоваться у малых и средних провайдеров доступа к сети Интернет для организации управляемого доступа. Схема опробована в инсталляции, насчитывающей около 15 000 пользователей.

Содержание

[править] Введение

Цель статьи — осветить базовые нюансы настройки для взаимной работы в паре двух программных продуктов:

  • Ideco АСР (Автоматизированная система расчетов, в народе "биллинг")
  • и MikroTik RouterOS.

Официальные сайты данных продуктов:

Прошу не путать два совершенно разных продукта Ideco ACP и Ideco ICS. (как выше уже писал - явно происходит разделение компании и постепенный ребрендинг Ideco ACP -> Carbon Billing)

[править] Установка и первичная настройка

Предполагается, что читатель владеет базовыми понятиями настройки сети и самостоятельно установил данные продукты и имеет доступ к ним с машины администратора. Для помощи используйте официальную онлайн документацию:

Проверьте, что обе системы "видят" друг друга (с помощью банального icmp ping).

Проверьте, что на микротике настроено подключение к вышестоящему провайдеру (интерфейс, маршрут по умолчанию).

И проверьте пингуется ли "мир" с микротика.

После этого можно переходить к следующему разделу.

[править] Лицензии

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

Демопериод на продукт Mikrotik ограничен 24 часами, но отсчет прекращается при выключении системы, другими словами можно тестировать 3 рабочих дня по 8 часов. После чего можно приобрести лицензию, которая стоит всего 45 USD на 200 VPN.

К слову, лицензию Ideco АСР на 200 юзеров можно получить легально и БЕСПЛАТНО, обратившись в отдел продаж компании разработчика. И у компании есть собственная разработка сервера доступа — Carbon AS 4 ® — в том числе и с бесплатной лицензией, о чем можно подробней прочитать на официальном сайте.

[править] Базовая Схема. Краткое описание

Cd7c181c87bf.png

Понятия:

  • MikroTik, далее NAS, Network Access Server — сервер сетевого доступа.
  • Ideco АСР, далее просто Биллинг.
  • Пользователь, далее юзер (от англ. user, пользователь).

Итак, упрощенное описание базовой схемы (ниже разберёмся подробней):

  1. Пользователь включает компьютер.
  2. Подключает VPN (PPTP/L2TP/PPPoE) на NAS (позже рассмотрим схему без VPN).
  3. NAS спрашивает у биллинга (через radius протокол), есть ли такой юзер в базе, правильный ли пароль, разрешен ли ему вход?
  4. Если "нет", то VPN не установится. Если да, то VPN установится.
  5. IP-адрес для VPN-клиента выдает биллинг через RADIUS-протокол.
  6. При этом в биллинге генерируется событие, которое запускает скрипт обработки событий и передает ему все параметры пользователя. Нас будут интересовать параметры скорости.
  7. Скрипт обработки событий через телнет "заходит" на NAS и добавляет IP адрес пользователя в список адресов.

Для каждого конкретного тарифа существует свой список (далее "адрес-лист").

Позже для данных списков настроим (один раз) правила фаервола и шейперы.

Таким образом трафик клиента проходит сквозь NAS, попадая в нужные ветки дерева очередей (шейпер) согласно адрес-листа, в который его поместил биллинг.

Периодически NAS скидывает подробную инфу о сетевой статистике пользователя биллингу (объемы входящего/исходящего трафика и т.д.).

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

Данное правило блокирует пакеты пользователя ("выключает интернет") и перенаправлет его на страничку "Превышен лимит. требуется пополнение баланса...".

Таким образом, весь трафик проходит через NAS, который является VPN сервером, шейпером, фаерволом, кеширующим DNS-сервером, NATит если надо, держит BGP сессии если надо и т.д.

При этом Биллинг стоит в сторонке и выполняет следующие функции: учет абонентов в базе данных, авторизация, ведение счетов, тарификация согласно тарифным планам, генерация событий, прием платежей, отчеты, интерфейс для администраторов, кассиров и прочих сотрудников компании. Личный кабинет для пользователей и прочее.

Далее рассмотрим подробней различные аспекты совместной работы двух систем.

[править] Базовая Настройка Ideco АСР

Инструкция актуальна для версии Ideco АСР 3.9.7

На более старых версиях существуют мелкие и болеe серьезные отличия, но я не буду их рассматривать.

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

[править] Создание пользователя root

Первым делом создайте пользователя root (по умолчанию суперпользователь отключён).

В официальной документации раздел называется Включение постоянного удаленного помощника" (не путать с устаревшим разделом: "Создание пользователя root").

[править] Консольное меню

Откройте консольное menu

0f4d8356d57d.png

[править] RADIUS

Настройте RADIUS сервер таким образом:

Конфигурирование сервера -> RADIUS-Сервер...

 [x] Включить RADIUS-сервер
 [x] Удалять лишние пробелы из логина RADIUS
 .
 .
 .
 [x] Использовать процедуры версии 6

[править] NetFlow

Конфигурирование сервера -> NetFlow коллектор...

 UDP-порт для приема         9996
 [x] Приём NetFlow потоков с разных источников

[править] SSH managment

для удаленного входа в консоль биллинга используется протокол SSH

Конфигурирование сервера -> Безопасность...

Поставьте отметку в следующих пунктах:

 [x] Разрешить управление файлами по SSH
 [x] Разрешить полное удаленное управление по SSH

и пропишите свой IP-адрес компьютера администратора:

Файл:0cf1dda0db01.png

Для возможности правки некоторых файлов нужно в локальном меню зайти в пункт Сервис и нажать на пункт "Разрешить запись из WinSCP на раздел с резервными копиями".

e3bd87c5c3c1.png

[править] События и скрипты

В локальном меню проверьте наличие галочки в пункте:

Конфигурирование сервера -> Дополнительные настройки -> Настройки для разработчиков...

 [x] Запускать скрипт обработки событий

3e513a6fffa1.png

Перезагрузите сервер Ideco корректно из меню:

699cbf874a8a.png

"Зайдите" на сервер с помощью SFTP на порт 33 под учетной записью root.

(если вы админите из-под венды :) - то один из популярных клиентов - это WinSCP)

Я в линухе "из коробки" ввожу прямо так:

E394e1c7e08e.png

Перейдите в директорию /var/lib/event/

Откройте на редактирование файл event_inc.sh

Выделите все и удалите. Затем вставьте следующее:

#/usr/bin/selfkiller -30:TERM -50:KILL & disown -a
LOG_LEVEL=ALL

sendsms(){
    sms="${sms//[^0-9]/}"
    if [ "${#sms}" -lt 11 ]; then                                                                                                                                           
        LOG WARN "Phone number of abonent $id is too short. SMS not sent."                                                                                                  
        return 1                                                                                                                                                            
    fi
    
}

SENDER=$1; shift
EVENT=$1; shift
DATA=$@

for VAR in $DATA; do
      [[ "$VAR" = *"="* ]] && eval ${VAR%%=*}=\'${VAR#*=}\'
done

LOG INFO "$SENDER $EVENT $DATA"

################################################################################################## 
telnet_user="user2"
telnet_password="YOUR_TELNET_PASSWD"
RADIUS_SECRET="YOUR_RADIUS_SECRET"

 case "$nas_ip" in
 "192.168.10.9")
 nas_identity="nas1"
 ;;
 "192.168.10.10")
 nas_identity="nas2"
 ;;
 "192.168.10.11")
 nas_identity="nas3"
 ;;
 esac
################################################################################################## 

case "$EVENT" in
################################################################################################## 
"balance_negative")
if [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then 
    /usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
################################################################################################## 
"balance_positive")
if [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then
    /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
fi
;;
################################################################################################## 
"rad_acc_start")
if [ "$nas_ip" != "0.0.0.0" ]; then
    if [ "$over_limit" = "0" ]; then
	/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
    else
	/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
    fi
fi
;;
################################################################################################## 
"rate_set")
if [ "$logged" = "1" -a "$nas_ip" != "0.0.0.0" -a "$over_limit" = "0" ] ; then 
    /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
fi
;;
##################################################################################################
user_data_changed|user_data_changed_before)
if [ "$nas_ip" != "0.0.0.0" ]; then
    echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
    /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"radius_update_err")
if [ "$nas_ip" != "0.0.0.0" ]; then 
    echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
    /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
user_disconnect|get_info_fail|rad_acc_timeout)
if [ "$nas_ip" != "0.0.0.0" ]; then
    echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
    /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"rad_acc_stop")
if [ "$nas_ip" != "0.0.0.0" ]; then 
    /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"try_double_login")
if [ "$nas_ip" != "0.0.0.0" ]; then
    echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
    /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"login") #Only for IP_auth
if [ "$nas_ip" != "0.0.0.0" -a "$auth_type"=1 ]; then
if [ "$over_limit" = "0" ]; then
/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
else
/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
fi
;;
################################################################################################## 
"logout") #Only for IP_auth
if [ "$nas_ip" != "0.0.0.0" -a "$auth_type"=1 ]; then
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
*)
:
;;
esac

Icon-caution.gif

Важно!!! Если в венде это делаете - Файл должен содержать unix символы окончания строки. (если не знаете, что это такое, и как в венде в разных текстовых редакторах выбрать тип окончания строки...погуглите (если, конечно, в "вашей стране" еще не закрыли доступ в гугл ))).

Запишите на бумажку:

  1. Замените - вместо YOUR_RADIUS_SECRET - свой придуманный "радиус секрет", запишите его на бумажке, он нам еще пригодится при настройке NASа.
  2. user2 - это имя специального юзера, которого мы позже заведем на NASе (под этим юзером биллинг будет "входить" на NAS).
  3. YOUR_TELNET_PASSWD - замените на свой придуманный пароль и запишите его (этот пароль не должен совпадать ни с каким другим - это пароль для юзера user2)
  4. nas1, nas2, nas3 - это названия ваших NASов. Задайте имя и IP адреса ваших Микротиков.(В Микротике - в разделе System -> Identity - задайте вместо nas1, nas2, nas3 - имена своих NASов (это не ДНС имена). Это Важно! И просто так от балды не меняйте название Микротика (либо не забывайте менять потом везде, где есть зависимость от этого имени).
  5. Адреса NASов 192.168.10.9, 192.168.10.10, 192.168.10.11 - конечно - заменить на свои (и понятно, что вы можете добавлять/удалять NASы - соблюдая синтаксис скрипта).
  6. Для схемы без VPN (IPoE) и без Radius - закоментируйте строки с radclient

Далее создайте в директории /var/lib/event/ три файла со следующими именами и содержимым:

event1.sh:

 #!/usr/local/bin/expect
 set nas_ip [lrange $argv 0 0]
 set ip [lrange $argv 1 1]
 set telnet_user [lrange $argv 2 2]
 set telnet_password [lrange $argv 3 3]
 set nas_identity [lrange $argv 4 4]
 spawn telnet $nas_ip
 expect "Login:"
 send "$telnet_user+ct\r"
 expect "Password:"
 send "$telnet_password\r"
 expect "$telnet_user@$nas_identity"
 send "/ip firewall address-list remove \[/ip firewall address-list find comment=$ip\] \r"
 expect "$telnet_user@$nas_identity"
 send "/ip firewall address-list add address=$ip list=list_balance_negative comment=$ip \r"
 expect "$telnet_user@$nas_identity"
 send "quit\r"
 expect eof
 

event2.sh:

 #!/usr/local/bin/expect
 set nas_ip [lrange $argv 0 0]
 set ip [lrange $argv 1 1]
 set telnet_user [lrange $argv 2 2]
 set telnet_password [lrange $argv 3 3]
 set nas_identity [lrange $argv 4 4]
 spawn telnet $nas_ip
 expect "Login:"
 send "$telnet_user+ct\r"
 expect "Password:"
 send "$telnet_password\r"
 expect "$telnet_user@$nas_identity"
 send "/ip firewall address-list remove \[/ip firewall address-list find comment=$ip\] \r"
 expect "$telnet_user@$nas_identity"
 send "quit\r"
 expect eof
 

event3.sh:

 #!/usr/local/bin/expect
 set nas_ip [lrange $argv 0 0]
 set ip [lrange $argv 1 1]
 set telnet_user [lrange $argv 2 2]
 set telnet_password [lrange $argv 3 3]
 set nas_identity [lrange $argv 4 4]
 set ceil_in [lrange $argv 5 5]
 set ceil_out [lrange $argv 6 6]
 spawn telnet $nas_ip
 expect "Login:"
 send "$telnet_user+ct\r"
 expect "Password:"
 send "$telnet_password\r"
 expect "$telnet_user@$nas_identity"
 send "/ip firewall address-list remove \[/ip firewall address-list find comment=$ip\] \r"
 expect "$telnet_user@$nas_identity"
 send "/ip firewall address-list add address=$ip list=list_${ceil_in}_${ceil_out} comment=$ip \r"
 expect "$telnet_user@$nas_identity"
 send "quit\r"
 expect eof
 

Установите на вышесозданные файлы - execute права.

Если Микротик в демо режиме - то он после входа предупреждает об оставшемся демо времени и требует нажать enter - значит добавьте в event1.sh event2.sh event3.sh после посылки пароля перед первой полезной командой несколько переводов строк:

send "\r\r\r"

(если добавите лишних "ентеров" - страшного ничего не будет).

а лучше купите лицензию на Микротик, которая стоит копейки. А если Вы - нищеброд и/или нарушитель авторских прав - скачайте образ с лицухой для виртуалки с этих ваших торрентов )

[править] Manager

Интерфейс управления Ideco Manager написан и скомпилирован под венду, но в wine работает без вопросов.

[править] Общие настройки

Сервис -> Настройки

E5be392f8822.png

Таймаут accounting update - данную переменную можете ставить сутки (в секундах, ессно).

[править] Оборудование

Добавим параметры нашего NASа по примеру:

61eea54a757d.png

[править] Пулы

Добавляете пул адресов, которые через RADIUS будут выдаваться юзерам в VPN тунели (не имеет значения - белые адреса, либо серые). Позже также мы рассмотрим варианты с "динамическими" и "статическими" адресами, а также нюансы с белыми и серыми адресами, и варианты без VPN тунелей и использование DHCP.

2ec78ce4ddc5.png

[править] Базовая настройка MikroTik ROS

[править] Identity

Как уже упоминалось ранее - имя вашего сервера Микротик нельзя менять от балды, по дефолту пропишите в разделе System -> Identity : nas1

5b0b2b6aa11b.png

[править] Clock

Нужно настроить время на NASе для нормальной работы и логов. Пропишите ближайшие к Вам два надежных сервера NTP.

5b2cb3dfe4a1.png

[править] Telnet group/user

В биллинге автоматически выполняются скрипты по различным событиям и производят определенные манипуляции на сервере NAS через telnet.

Ка уже выше писалось - я просил записать на бумажку имя телнет юзера user2 и придуманный вами пароль, который вы ранее прописали в скриптах обработки событий.

Пришло время настроить специальную группу и этого юзера на Микротике:

Открывайте в winbox меню: System -> Users

и там щелкаете по вкладке Groups

Затем на плюс (добавить новую группу).

Придумайте имя группы (например telnet)

Расставьте галочки напротив следующих прав:

 - write
 - test
 - telnet
 - read
 

нажмите Ok.

D3b988179489.png

Далее жмите вкладку Users.

Добавляйте нового юзера с именем user2 и выбирите из нисподающего списка имя вышесозданной группы.

Обязательно укажите, что доступ этому юзеру разрешен только с IP адреса биллинга - в поле Allowed Address: укажите IP адрес вашего билинга.

Укажите и подтвердите пароль созданного юзера user2 (тот, что я просил выше придумать вместо YOUR_TELNET_PASSWD и записать на бумажке)

6995efa7efae.png

[править] DNS

Для корректной работы интернет сервисов необходимо настроить службу DNS.

Схема такая - на Микротике включаем кеширующий днс. Указываем ему несколько надежных днс служб - обычно используются серверы вышестоящего провайдера (Не рекомендую более двух серверов указывать). И нашим юзерам, например с помощью опции DHCP - передаем в качестве днс сервера - локальный адрес NAS сервера. Таким образом юзер делает днс запросы на Микротик сервер, если у него в кеше нету такой записи, то микротик делает запрос в прописанные "вышестоящие" днс серверы, и затем возвращает ответ нашим юзерам. Все это происходит обычно быстрее, чем вы читаете этот абзац )))))


E8139d99b8af.png

[править] DHCP

Если Вы используете DHCP на NASе, то отключите его в биллинге.

Запустите мастера настройки DHCP сервера на Микротике.

F6a4a1263577.png

Подробно пока не буду заострять внимания на этих банальных настройках - в Сети множество примеров.

Лишь некоторые очевидные нюансики:

Юзеры должны находится в одном сегменте с сервером DHCP (один VLAN, один широковещательный домен) - иначе нужно использовать DHCP Relay (обычно включают эту фишку на "умном" коммутаторе).

При настройке DHCP сервера - одна из опций, которая юзерам передается кроме IP адреса - это адрес DNS сервера - проверьте, чтобы этот адрес был адресом локального фейса Микротика.

Если вы решили использовать авторизацию PPPoE для юзеров - то выдавать IP адреса на физический интерфейс юзеров - не обязательно - тунель работает на основе MAC адресов клиента и сервера (на втором уровне (L2) семиуровневой модели OSI). (Но если все таки юзерам нужно видет друг друга в локалке мимо тунеля и сервера - тогда, конечно, назначайте адреса на физические фейсы юзерских девайсов).

[править] VPN (secret/profile/radius)

Самый лучший из тунелей - это PPPoE - так как он кушает гораздо меньше ресурсов, чем PPTP - потому что в микротике реализован как модуль ядра ("ядерный"), в отличие от PPTP/L2TP - демоны которых крутяться в userspace - пространстве для юзеров и из-за частой смены контекста выполняются "лишние" операции.

С PPPoE есть нюанс - клиент и сервер должны быть в одном сегменте Ethernet, в противном случае нужно использовать PPPoE agent на управляемых свичах, чтобы релеить пакеты из одного сегмента в другой. Любо юзать вместо PPPoE - PPTP (не рекомендую) либо L2TP тунели. Ну, а вообще можно хоть одновременно все три типа тунелей юзать - но кому такой зоопарк нужен? А еще лучше не юзать тунели вообще (так называемый IPoE), но об этом потом....

Итак - если вы решили юзать PPPоE - отключите PPPoE сервер в биллинге:

1484afa87036.png

Далее настройте профиль default:

798feb700475.png

и

De78a5f63cfd.png


Затем включите радиус аутентификацию и аккаунтинг, и создайте ppp секрет, при этом выбирите из нисподающего списка нужный Вам Service:


Ebfff5a9b21d.png

Включаем PPPoE сервис на локальном интерфейсе с профилем default:

08274ccdb2f6.png

Если вместо PPPoE решили юзать PPTP или L2TP - включите нужный Вам сервис:

84cef8874df8.png

[править] Traffic Flow

Для подсчета объемов трафика и сбора подробной статистики нужно отсылать биллингу инфу о проходящем сквозь NAS трафике юзеров:

0356d6ff15f4.png

Включите traffic flow, выбирите все интерфейсы (all) и укажите куда отсылать netflow v5 - адрес вашего биллинга.

[править] Radius Accounting

Я лично отсылаю netflow версии 9 не на биллинг, а на отдельный сервер. (для справки - я юзаю debian + nfdump + nfsen). А объемы трафика у меня в биллинге считаются не с помощью netflow, а с помощью Radius протокола.

F118f4e0c220.png

Это нужно, когда у вас десятки тысяч юзеров и гигабиты трафика в секунду - чтобы не напрягать биллинг. Таким образом легко можно масштабировать NetFlow коллекторы - например условно на каждых 5 NASов - свой нетфлоу коллектор.

Минус такого метода один - с помощью радиуса мы можем считать только объемы, но биллинг ничего не будет знать об посещаемых IP адресах, а значит не сможем сделать в помегабайтных тарифах - льготные или бесплатные ресурсы. Но в век безлимитов этот нюанс имеет все меньше и меньше значения. Сейчас "льготность" может заключаться в бОльших скоростях на льготные ресурсы - о чем мы поговорим позже.

Еще одно замечание - по умолчанию NAS скидывает промежуточную информацию (Radius Accounting) на биллинг каждые 300 сек. Если юзеров очень много (тысячи их) - есть смысл это время увеличить. Для этого нужно в биллинге в манагере в настройках каждого тарифа - > во вкладке RADIUS - добавить такой атрибут:

Acct-Interim-Interval := 2400 

(важно - в общих настройках в манагере радиус аккаунтинг таймаут должен быть больше чем Acct-Interim-Interval, и как я уже выше советовал - ставьте таймаут сутки)

[править] RADIUS

Включаем radius пока только для VPN (ppp), позже рассмотрим работу radius + DHCP и + Hotspot

Eae38e5b953f.png

Прописываем адрес биллинга. И указываем ваш радиус секрет (тот, который вы придумали YOUR_RADIUS_SECRET)

[править] Тарифы. Ideco

Рассмотрим четыре базовых тарифа и "турбокнопку".

Пронумеруем для удобства эти сущности.

Прежде чем создать тарифы - создайте в Ideco Manager "правила и сети". А лучше воспользуйтесь заготовками, которые есть в базе данных для примера. И не забывайте про онлайн документацию.

[править] Простой безлимит (№1)

Dd19953e602e.png

Пусть вас не смущает, что я написал скорость "1". Это не килобиты в данном случае, а номер, который будет передаваться в Микротик. Есть лицензия на Ideco - которая позволяет обойтись без использования NAS и пропускать трафик через сервер биллинга - в этом случае тут пишутся реальные скорости в килобитах для шейпера Ideco SoftRouter. В нашем случае трафик идет не через Ideco, а через Микротик - там мы и будем позже настраивать шейпер.

Не забудьте поставить галочку "блокировать при превышении лимита".

Не забудьте указать абонентскую плату.

Note-icon.gif

В описываемой мной схеме - RADIUS атрибуты в тарифе прописывать не нужно!!!

7a88f3b62132.png

[править] Условный безлимит (скорость зависит от объема)(№2)

Ed8c10cee402.png

До 200 Гигов входящего объема - скорость номер 2

A85365aa5229.png


После 200 Гигов входящего объема - скорость номер 22 - до конца месяца.

35f51c301cb9.png

[править] "Помегабайтный" (цена зависит от объема) (№3)

Ed0a1a7fc802.png

Тут никто не мешает добавить других правил и подсетей с другой стоимостью мегабайтов. И никто не мешает указать разную стоимость трафика для разных объемов, времени суток, и для входящего и исходящего - раздельно.

[править] Безлимит - разная скорость в разное время суток (№4)

D1fbdc2856dc.png

Note-icon.gif

Внимание! Мы будем менять скорость в разное время суток для этого тарифа - на Микротике (об этом позже). Поэтому тут в Ideco не нужно указывать время и скорость.

[править] Турбокнопка (№5)

4657a9a9e7e0.png

Укажите стоимость услуги, номер скорости, время действия турбо-режима, и разрешите заказ через веб кабинет.

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

37d92db5de90.png

[править] Настройка группы и "карточки" юзера

Создайте группу по примеру:

277309f71e9a.png

Cоздайте юзеров по примеру:

4f19a5fd80fa.png

Комментарии:

Не используйте заглавные буквы, кирилицу, пробелы в логинах юзеров!!!

Уберите галочку isNAT - даже если Вам нужен NAT - мы его настроим позже на Микротике.

Внимательно с признаком "финансовый" и "порогом отключения" и "периодом формирования акта" (варианты использования - в официальной документации)

[править] Тарифы. MikroTik

[править] Дерево очередей. Родители.

Переходим к так называемому шейперу.

Кого интересует теория - нужно почитать мой перевод презентаций cотрудника MikroTik (Megis) здесь: [1] и [2] а также статья MikroTik QoS: развенчание мифов Habrahabr.png

Итак:

создадим один раз родителей дерева очередей:

Методом "копипасты" вставляйте в terminal:

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=Total_download packet-mark="" parent=global-out priority=1
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=Total_upload packet-mark="" parent=global-out priority=1

[править] Маркировка трафика в Mangle

Итак, настроим маркировку трафика в двух направлениях (download/upload) для наших четрыех тарифов и турбокнопки:

Копипастим в терминал:

Для тарифа №1

/ip firewall mangle
add action=mark-packet chain=forward comment=list_1_1_up disabled=no new-packet-mark=mark_1_up passthrough=no src-address-list=list_1_1
add action=mark-packet chain=forward comment=list_1_1_down disabled=no dst-address-list=list_1_1 new-packet-mark=mark_1_down passthrough=no

Для тарифа №2

правило до 200 гигов

/ip firewall mangle
add action=mark-packet chain=forward comment=list_2_2_up disabled=no new-packet-mark=mark_2_up passthrough=no src-address-list=list_2_2
add action=mark-packet chain=forward comment=list_2_2_down disabled=no dst-address-list=list_2_2 new-packet-mark=mark_2_down passthrough=no

правило после 200 гигов

/ip firewall mangle
add action=mark-packet chain=forward comment=list_22_22_up disabled=no new-packet-mark=mark_22_up passthrough=no src-address-list=list_22_22
add action=mark-packet chain=forward comment=list_22_22_down disabled=no dst-address-list=list_22_22 new-packet-mark=mark_22_down passthrough=no

Для тарифа №3

/ip firewall mangle
add action=mark-packet chain=forward comment=list_3_3_up disabled=no new-packet-mark=mark_3_up passthrough=no src-address-list=list_3_3
add action=mark-packet chain=forward comment=list_3_3_down disabled=no dst-address-list=list_3_3 new-packet-mark=mark_3_down passthrough=no

Для тарифа №4

/ip firewall mangle
add action=mark-packet chain=forward comment=list_4_4_up disabled=no new-packet-mark=mark_4_up passthrough=no src-address-list=list_4_4
add action=mark-packet chain=forward comment=list_4_4_down disabled=no dst-address-list=list_4_4 new-packet-mark=mark_4_down passthrough=no

Для нашей турбокнопки:

/ip firewall mangle
add action=mark-packet chain=forward comment=list_5_5_up disabled=no new-packet-mark=mark_5_up passthrough=no src-address-list=list_5_5
add action=mark-packet chain=forward comment=list_5_5_down disabled=no dst-address-list=list_5_5 new-packet-mark=mark_5_down passthrough=no

В итоге должно получится вот так:

744d9be53f95.png

                                • Начало #Это можно не читать ) *****************

Как видим - не так, как в примере в презентации Мегиса: - родители Global-Out - маркировка пакетов отдельно для upload и download трафика - нет маркировки соединений

Суть

Global-Out или Interface HTB? Существует два основных отличия В случае SRC-NAT (masquerade) - Global-Out будет знать о частных адресах клиента, но Интерфейс HTB не будет - интерфейс HTB находится после SRC-NAT. Каждый интерфейс HTB получает только трафик, который будет отправится через определенный интерфейс - нет необходимости в разделении upload и download в mangle

Другими словами, я показываю универсальный пример с использованием Global-Out и маркировкой пакетов - а не маркировкой соединений, и маркировка осуществляется раздельно для up и down трафика - это универсально работает и c реальными адресами (можно вообще тогда нафиг conntrack вырубить) и с маскарадингом (NAT) и с hotspot и с pppoe/l2tp/pptp тунелями и с IPoE. Но если Вы поняли тонкости - вам никто не мешает использовать другие схемы и инструменты.

                                • Конец #Это можно не читать ) *****************

[править] Cоздание типов очередей PCQ

В итоге скорость содержится в значении параметра pcq-rate=

Т.е. для первого тарифа сделаем для примера скорость 20M/10M

В итоге потом можно в любое время эту скорость менять даже на ходу. При этом юзеры даже не заметят - обрыва не будет - ни VPN сессии, ни TCP/UDP/GRE соединений.

Теперь понимаете, почему в настройках тарифов в Ideco Manager я писал именно номера, вместо скорости в килобитах? Для гибкости. Можно было сразу там писать скорость, и потом во всех правилах тоже, но тогда при смене скорости тарифа - везде надо было эти цифры менять, а так только парметр pcq-rate= в WinBox на ходу меняем при необходимости - и всё.

Итак Для тарифа №1 - скорость 20M/10M

/queue type
add kind=pcq name=pcq_1_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=20M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_1_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=10M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000

Для тарифа №2

Сделаем для примера скорость 20M/10M для объема до 200 гигов

/queue type
add kind=pcq name=pcq_2_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=20M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_2_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=10M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000

и сделаем скорость 512k/512k для объема после 200 гигов

/queue type
add kind=pcq name=pcq_22_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_22_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000

Для тарифа №3

Сделаем для примера скорость 30M/30M

/queue type
add kind=pcq name=pcq_3_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=30M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_3_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=30M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000

Для тарифа №4

Сделаем для примера скорость 2M/2M в дневное время (планировщик, который меняет скорость в ночное время на 50M/50M сделаем чуть позже)

/queue type
add kind=pcq name=pcq_4_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=2M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_4_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=2M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000


Для нашей турбокнопки сделаем скорость 90M/90M:

/queue type
add kind=pcq name=pcq_5_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=90M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000
add kind=pcq name=pcq_5_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=90M pcq-src-address-mask=32 pcq-src-address6-mask=64 \
   pcq-total-limit=64000

В итоге должно получиться так:

936279405a39.png

И как я говорил выше - можно в любой момент тюнить скорость без всяких разрывов, меняя параметр pcq-rate=

[править] Создание листьев в дереве очередей

Теперь создаем ветки шейпера на основе созданных нами правил разметки трафика и созданных типов очередей: (копипастим в терминал):

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_1_up packet-mark=mark_1_up parent=Total_upload priority=1 queue=pcq_1_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_1_down packet-mark=mark_1_down parent=Total_download priority=1 queue=pcq_1_down
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_2_up packet-mark=mark_2_up parent=Total_upload priority=1 queue=pcq_2_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_2_down packet-mark=mark_2_down parent=Total_download priority=1 queue=pcq_2_down
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_22_up packet-mark=mark_22_up parent=Total_upload priority=1 queue=pcq_22_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_22_down packet-mark=mark_22_down parent=Total_download priority=1 queue=pcq_22_down
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_3_up packet-mark=mark_3_up parent=Total_upload priority=1 queue=pcq_3_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_3_down packet-mark=mark_3_down parent=Total_download priority=1 queue=pcq_3_down
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_4_up packet-mark=mark_4_up parent=Total_upload priority=1 queue=pcq_4_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_4_down packet-mark=mark_4_down parent=Total_download priority=1 queue=pcq_4_down
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_5_up packet-mark=mark_5_up parent=Total_upload priority=1 queue=pcq_5_up
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=0 name=queue_5_down packet-mark=mark_5_down parent=Total_download priority=1 queue=pcq_5_down


В итоге получаем окончательный шейпер (дерево очередей) для наших тарифов и турбокнопки:

45e6851bbfec.png


[править] Расписание изменения скорости для тарифа №4

У нас есть тариф, где нам нужно менять скорость, например днем 2M/2M, а ночью 50M/50M, (при этом можно конкретные часы/минуты/секунды можно менять произвольно, и при этом ничего не нужно править в биллинге):

/system script
add name=tariff4a policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api source="queue type set pcq_4_down pcq-rate=2M;\r\
   \nqueue type set pcq_4_up pcq-rate=2M;"
add name=tariff4b policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api source="queue type set pcq_4_down pcq-rate=50M;\r\
\nqueue type set pcq_4_up pcq-rate=50M;"
/system scheduler
add disabled=no interval=1d name=tariff4a on-event=tariff4a policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api start-date=mar/19/2012 start-time=08:00:00
add disabled=no interval=1d name=tariff4b on-event=tariff4b policy=ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api start-date=mar/19/2012 start-time=23:59:59

Естественно, можно сделать и больше диапазонов (сколько угодно раз в сутки менять скорость нашего тарифа #4)

В итоге получаем:

5d7869d4edbb.png

[править] Тарифы и Firewall Filter

Итак закончили с разметкой трафика и шейпингом - теперь приступим к фильтрации трафика:

  • Нужно заблокировать трафик для тех, у кого отрицательный баланс
  • разрешить "авторизованный трафик" для залогиненых юзеров (для всех тарифов и турбокнопок)
  • и запретить любой остальной "неизвестный трафик".

Копипаста в терминал:

/ip firewall filter
add action=drop chain=forward comment="balance negative src" disabled=no src-address-list=list_balance_negative
add action=drop chain=forward comment="balance negative dst" disabled=no dst-address-list=list_balance_negative
add action=accept chain=forward comment=list_1_1_src disabled=no src-address-list=list_1_1
add action=accept chain=forward comment=list_1_1_dst disabled=no dst-address-list=list_1_1
add action=accept chain=forward comment=list_2_2_src disabled=no src-address-list=list_2_2
add action=accept chain=forward comment=list_2_2_dst disabled=no dst-address-list=list_2_2
add action=accept chain=forward comment=list_2_2_src disabled=no src-address-list=list_22_22
add action=accept chain=forward comment=list_2_2_dst disabled=no dst-address-list=list_22_22
add action=accept chain=forward comment=list_3_3_src disabled=no src-address-list=list_3_3
add action=accept chain=forward comment=list_3_3_dst disabled=no dst-address-list=list_3_3
add action=accept chain=forward comment=list_4_4_src disabled=no src-address-list=list_4_4
add action=accept chain=forward comment=list_4_4_dst disabled=no dst-address-list=list_4_4
add action=accept chain=forward comment=list_5_5_src disabled=no src-address-list=list_5_5
add action=accept chain=forward comment=list_5_5_dst disabled=no dst-address-list=list_5_5
add action=drop chain=forward disabled=no

Примечание - не забывайте, что в фаерволе имеет значение порядок следования правил.

[править] NAT

Если Вы раздаете юзерам серые адреса и у Вас на внешнем фейсе в Микротике один белый (реальный) адрес - не забудьте настроить маскарадинг. В самом простом случае:

/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1-Ext

где ether1-Ext замените на имя вашего внешнего интерфейса.

Другие варианты настройки NAT выходят за рамки этой статьи. В Сети сущестует множество примеров.


[править] Динамическая раздача IP адресов

Для экономии белых адресов есть смысл раздавать их динамически и сохранять логи для спецслужб.

Для динамической выдачи адресов существует соответствующая вкладка в настройке тарифа в Ideco Manager:

"Динамический IP/NAT"

Пул адресов привязывается к юзеру в его "карточке" (вкладка "Информация" в Ideco Manager).

Если нужно выдавать адреса из пулов, привязанных к конкретным NASам, тогда пул привязывается в настройке каждого NAS в Ideco Manager:

"Оборудование" -> "Маршрутизаторы" -> "открываете" нужный NAS и в соответствующем нисподающем списке "Динамические IP" - выбираете пул.

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

Все вышесказанное - в контексте использования RADIUS протокола.

[править] IPoE авторизация

Есть тенденция избежать использование тунелей VPN (PPTP, L2TP, PPPoE) - чтобы упростить жизнь юзерам. Ведь VPN тунели изначально придумали совсем не для того, чтобы "подключаться к интернету". Это уже позже их к этому приспособили.

Но на самом деле не существует никакой "авторизации IPoE". Что означает эта аббревиатура?

Что такое IPoE?

Ответ: IP over Ethernet. Вдумайтесь. Это обычные IP пакеты, которые передаются по Ethernet сети - т.е. любая офисная локалка подпадает под эту аббревиатуру ). Т.е. самый обычный роутинг/свитчинг IP пакетов в сети Ethernet - более 30 лет существует - и авторизация как бы совсем нипричем. Это НЕ стандарт, НЕ протокол!

Но в наших краях под IPoE подразумевают - условную концепцию отсутствия тунелей для осуществления доступа в интернет. А далее разные вендоры придумывают кто во что горазд - каким образом осуществлять AAA (Authentication, Authorization, Accounting).

Так же IPoE подразумевает "особый" подход к дизайну сети и выбору оборудования как на доступе, так и в "центре". На эту тему есть множество холиваров. И это выходит за рамки этой статьи.


[править] IPoE с Radius

[править] DHCP Mikrotik + MAC + Radius

В Микротике есть возможность связать DHCP с RADIUS.

Cd26baaca499.png


Другими словами - когда клиент делает DHCP запрос - Микротиk будет "переспрашивать" в биллинге через RADIUS - можно ли юзеру выдать адрес, и если можно, то какой.

Профита от этой схемы пока мало - из коробки Ideco на данный момент не готова для этой схемы - потому что нужно надфилем подпилить процедуры. В частности Микротик шлет пустое поле пароля - Ideco это не "нравится". Можно с помощью костылей "воткнуть" "общий" пароль, но зачем? )

И есть еще один нюанс - DHCP MikroTik не умеет Radius аккаунтинг. Т.е. объемы нужно в любом случае считать с помощью netflow (99,99999% так и делают). Но вот логика Ideco завязана на radius update пакеты - чтобы юзер оставался "онлайн" . Дальше пока даже не стал разбираться с нюансами: dhcp lease time, release (освобождение адреса), переподключения и прочие заморочки из реальной жизни.

[править] DHCP Mikrotik + Opt.82 + Radius

Тут справедливо все вышесказанное, с той лишь разницей, что Тик может еще и опц82 передавать в радиус запросе для биллинга. И в биллинге можно ее анализировать вместо MAC юзера. (MAC можно игнорить - нафег он нам нужен). Для этого нужно прописать адрес DHCP relay (если релеев много - значит указать "принимать со всех - 255.255.255.255 или 0.0.0.0 - точно не помню - попробуйте оба варианта).

B1b27531d95e.png

Недостатки схемы те же, что и в предыдущем случае. К тому же - в ideco нужно правильно "разбирать" поля опции82 - так как они для разных вендоров разные - тоже из коробки не будет работать пока-что. Если кому сильно надо - нужно обращаться к разработчкиам - они подпилят. (Конечно, если у Вас не бесплатная лицензия, поддержка на которую не оказывается). Хотя на демо версию - поддержка есть. И если Вы убедите их - что Вы - потенциальный клиент - собрались купить лицензию, и лишь "вот этот вот нюанс" вас останавливает ....)))

[править] WiFi и HotSpot: Web авторизация + CHAP + Radius

Данная схема абсолютно рабочая и кошерная.

Позиционируется для настройки беспроводных точек доступа Микротик и беспроводных клиентов (аля смартфоны/нетбуки/планшеты - в гостиницах, общагах, библиотеках и прочих аэропортах.

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

Расставляем точки доступа Микротик. Настраиваем их в биллинге как и "обычные" NAS Микротик.

С той лишь разницей - на точках доступа используется не VPN, а HOTSPOT - в котором есть полноценный RADIUS c аккаунтингом:

6a3ed6a90ef2.png

Включаем Web авторизацию + CHAP:

Dba8e01fd594.png

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

Также можно указать сайты, которые могут быть доступны без авторизации (Walled Garden).

В Сети легко находятся примеры настройки MikroTik HotSpot и Wireless.

Плюсы - юзерам со смартфонами не нужно (не возможно) возиться с тунелями - вместо этого есть понятное окошко веб-авторизации.

Минусы - нету. (просто нужно понимать нишу - для которой эту схему нужно юзать)


Кстати - HotSpot работает не только на беспроводном фейсе, но и вполне себе на Ethernet интерфейсах. О чем ниже...

[править] WiFi и Ethernet HotSpot: MAC+Radius

Можно использовать авторизацию по MAC адресу.

!!! При этом, напоминаю, HotSpot не только для беспроводной сети - он отлично работает и на ethernet интерфейсах. И если веб авторизация явно предназначена для беcпроводных клиентов в лице разных мобилок и прочих девайсов аля планшетики, то хотспот + MAC авторизация - вполне органично может использоваться в Ethernet сети для проводных клиентов.

7a66ac754671.png

На ideco соответственно вместо имени и chap пароля юзера - проверяется только MAC адрес юзера и общий пароль. (на скрине выше заполните поле MAC Auth. Password ), и пропишите этот "общий" радиус пароль в Ideco Manager - в св-вах соответсвующего NASa ("оборудование" - "маршрутизаторы" - ... выбираем NAS ... - "USERS_PSW" ):

cc975314fe76.png

MAC передается заглавными символами. По-поводу дефисов и двоеточий - выбирайте шаблон в Тике в ниспадающем списке "MAC Format" ("IP - Hotspot - Radius"):

f22db194be50.png

!!! Внимание - вписывайте MAC в поле "Логин" - в карточке юзера в Ideco менеджере.

bcea2859e234.png

!!! Нужно отключить фишку на Ideco, которая режет пробелы и заглавные символы в радиус запросах (да - таки эта фишка кроме пробелов еще режет символы A-Z - чуть ниже расскажу зачем вообще она нужна):

B6b501aba4cf.png

(кстати - никто не мешает редактировать и тюнить на Ideco - конфиг freeradius сервера - если понимаете что и для чего...)

Внезапно в подсказке написано, что эту фишку "Не используйте, если отключаете сессии по логину".

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

Отключайте эту фишку - если киляете не по имени (а по адресу и id радиус сессии - но тогда отредактируйте соответственно скрипт обработки событий), или не юзаете VPN или Web авторизацию.

В ideco манагере - в общих настройках - параметр "Регистрозависимый логин" вообще никогда не включайте - на данный момент оно работает так:

Приходит запрос радиус с NAS - мол - вот вам имя и пароль - есть ли такой юзер? Разрешен ли ему вход и какой адрес и прочие параметры ему выдать? Если регистр не совпадает - сервер должен бы ответить отказом - т.е. нельзя этому юзеру входить. Но Ideco просто не выдает IP адрес - "сервер не назначил адрес". Тогда юзер сам себе назначает адрес (да, прямо в настройках впн) и спокойно подключается. Страху, конечно, никакого - но юзеры часто любят прописать себе на виртуальный фейс - адрес самого впн сервера или еще какого-нить девайса вашей сети или соседа - и тогда происходят весьма интересные вещи.... Попробуйте сами )))))

Итоги:

Схема - рабочая. Если не смущает собирать мак адреса клиентов и есть возможность обеспечить защиту от подмены мак адресов. Условно позиционируем эту схему для небольшой сети.

[править] VirtualAP

Например: в торговом центре есть ваши точки доступа. 90% юзеров юзают говносмартфоны и говнопланшеты. Но есть 10% - которым нужно подключить какие-то банковские терминалы и прочие вундервафли, которые не умеют ни впн, ни веб авторизацию и вообще вай фай не умеют )))

Ставим им тоже вайфай роутер (например - клиентский микротик RB751 - в нем таки уже есть внешняя и внутренняя антены - настраиваем там прием по внешней, раздачу - с внутренней - на другой частоте. Авторизацию на нем - внимание - VPN !!! (это мы уже умеем). Роутер раздает внутри помещения (мощность можно поубавить) опять же на говносматрфоны клиента по ключу (их личная частная сеть). А вундервафлю клиента (банковский терминал и прочие стационарные штуки) вообще включаем проводами к юзерскому роутеру, который уже "авторизован" и раздает невозбранно Инет всем подключенным по - внезапно IPoE ).

Для того, чтобы наша (провайдерская) точка доступа могла и хотспот и впн одновременно - придумали Virtual AP - создаем на физическом беспроводном фейсе сколько нужно виртуальных AP - каждая из которых может иметь свой SSID, и типы авторизации (на одной AP включаем hotspot, на другой не включаем и юзаем VPN как обычно), а также наличие/отсутствие своих ключей. Для веб авторизации - оставить видимую беспроводную сетку без ключа. Для остальных извратов - сетку скрыть - ключом закрыть и настраивать индивидуальные роутеры клиентов - чтобы остальных не путать.

[править] IPoE без Radius

Особенности и причины использования IPoE без RADIUS AAA.

Подведем промежуточные итоги:

Если юзать DHCP на Тике без радиус - биллинг вообще ничего не знает о адресах юзера. Схема не кошерная.

Если юзать DHCP на Тике + радиус - биллинг выдает адреса и все почти хорошо, кроме тог, что схема не допилена). (Знаю людей, которые юзают эту схему с самописным биллингом (они то и пропихнули тему - чтобы тиковцы запилили поддержку DHCP + Opt82 + radius ))

Если юзать хотспот - то все кошерно, но больше подходит для беспроводных клиентов.

Поэтому рассмотрим следующие варианты:

[править] DHCP Ideco + Opt.82

Итак, Микротик dhcp + radius + Ideco = пока не взлетел.

Значит нужно юзать DHCP на биллинге - чтобы он таки был в курсе выданных адресов клиентам.

Настройки DHCP Ideco описаны в оффициальной документации.

!!! Скрипт обработки событий универсальный - не требует допила - !!! можно юзать смешанную схему - и VPN и ip авторизацию. Соответственно и настройки NASа в Ideco - ничем не отличаются:

61eea54a757d.png

(пусть вас не смущают галочки "лишние" - это для универсальности: VPN + radius и схема IPoE без радиус могут работать одновременно!). Понятно, что радиус и впн можно и не настраивать - IPoE все равно будет работать!


Особенности:

В этой схеме - юзеру выставляется тип "авторизации по IP".

Так как приходится обходится без радиуса - то биллинг ни черта не в курсе через какой NAS там форвардится юзерский траф - поэтому в "карточке" клиента нужно прописать NAS IP и залочить галочку.

36223c24f223.png

Недостаток схемы - из-за отсутствия радиуса - нет фактического логина/логаута - нет постоянной "актуализации" в каком листе юзер должен находиться. Событие "логин" происходит формально один раз. Юзер как бы подключен всегда - нет явных сессий по факту. Трафик рулится с помощью редких событий - баланс негатив и позитив (так как юзеры платят сразу за неделю или даже месяц). В итоге может происходить "рассинхрон" между биллингом и NAS.

Пару примеров - почему это может произойти:

- Юзер заплатил деньги. Произошло событие "баланс позитив". В этот момент NAS был в ребуте или связь временно между серверами отсутствовала (достаточно одну команду всего потерять). И далее юзер может хоть сто раз перезагружаться - он остается в адрес лист негатив. Так же верна и обратная ситуация - денежки кончились у юзера - не прошло событие баланс негатив по любой из причин - и потом ваш юзер может использовать Инет без денег хоть полгода - пока биллинг не перезагрузишь.

  • NAS пришлось менять на новый - придется актуализировать вручную адрес-листы.
  • Понадобилось восстановить конфиг NASа из бэкапа - также придётся актуализировать вручную адрес-листы.

и т.д.

Понятно - что в жизни потеря команд будет не часто происходить. Но все же периодически рекомендуется делать сверку "вручную" между биллингом и NASом.

Достоинства схемы - простая до безобразия.

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

Рекомендуется для относительно небольшой сети.

Внезапно можно написать скрипт или программку синхронизации биллинга и NAS и запускать в планировщике по расписанию с заданным интервалом. Тогда можно и для относительно большой сети эту схему применить.

[править] DHCP Ideco + MAC

Тоже самое, что и предыдущая схема, только вместо опции82 - юзается MAC - для раздачи адресов.


[править] IPoE без DHCP и Radius

Можно в карточке юзера:

  • прописать его адрес вручную
  • IP NAS прописать и залочить
  • поставить ip авторизацию

и тоже все ок работает. Я юзаю такую схему для серверов и прочих хитрых девайсов - на них адреса прописаны руками и отдельный тариф придуман.

Но никто не мешает юзать и для юзеров такую схему) (Есть еще такие, кто не юзает DHCP, а прописывает руками и делает привязки и фильтры на свичах - почему бы и нет - если оно работает))

[править] Разное

[править] Редирект отрицательный баланс

IRL - удобно пользователей с превышенным лимитом отправлять на специальную страничку - где ему объясняется, что, мол, кончились денежки на счету у поциента). И там же описываете множество способов оплаты и размещаете прочие разные памятки и "важную полезную инфу" ).

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

Существуют разные варианты перенаправления. В Нете достаточно примеров. У каждого есть свои плюсы и минусы. Я не ставлю цель рассказать про эти тонкости - Вы должны сами понять и выбрать для себя "свои любимые фломастеры".

Я опишу кратко только один способ - в нём не используется ни прокси, ни http редиректы, ни сложные конфиги вспомогательных веб серверов, ни прочие различные сложные извращения ... Ибо однажды я имел случай со своим домашним провайдером - как-то я (вернее жена )))) забыла закинуть денег. У меня обычно в браузере открыто десятки вкладочек с полезностями - которые еще не успел прочитать/изучить. И вот я запускаю браузер - все вкладочки "отправились" на страничку провайдера "превышен лимит". Оригинальные url в адресной строке - все заменены на url провадерского портала. Потеря потерь ))) Я предлагаю варинат - где url в адресной строке не трогаются совсем - т.е. - там, например, написано lurkmore.to - а отображается страничка провайдера "превышен лимит" - и после пополнения баланса браузер перезапускаете и имеете оригинальный url и его оригинальное содержимое.

В общем виде суть такая:

  • имеем веб сервер в локалке с дефолтной страничкой "превышен лимит" . Проверяем - что он "виден" с NASов - на локальном фейсе.
  • перенаправляем трафик для "негативных юзеров" TCP 80 c помощью DNAT на IP адрес, где установлен веб сервер со страничкой "Превышен лимит"
  • создаем правило SNAT - которое маскарадит трафик "негативных" юзеров на локальном фейсе - с условием - что адрес назначения = наш веб-сервер со страничкой "Превышен лимит".

Это правило поднять выше того, которое маскарадит весь трафик в Инет (если есть такое).

  • разрешаем в форварде трафик с/на адрес веб-сервера со страничкой "Превышен лимит" для негативных юзеров.

Это правило поднять выше того, которое блокирует весь трафик "негативных юзеров".


Данная схема мне нравится своей простотой. И тем, что у юзера в браузере не коцаются все ссылки при наступлении минуса. И не нужно килять юзера при достижении минуса - не нужно менять ему адрес на его интерфейсе из "специального пула для "отрицательных" юзеров или помещать в другой влан и заморачиваться с дополнительными настройками свичей и роутеров - чтобы рулить "специальной" сеткой или VLANом.

Юзер как только пополняет баланс - без всяких переподключений - тут же по событию из биллинга убирается из "негативного" адрес листа - помещается в нужный - согласно тарифу - и трафик пошел в "Инет".

Вот примеры команд - где вы должны сменить наименование фейса и адрес веб сервера на свои:

(не забудьте потом "перетащить" правила на нужные места (ибо порядок следования правил важен))

 /ip firewall nat
 add action=masquerade chain=srcnat comment="negative snat" disabled=no dst-address=192.168.254.3 dst-port=80 out-interface=ether3-Local protocol=tcp
 add action=dst-nat chain=dstnat comment="negative dnat" disabled=no dst-port=80 protocol=tcp src-address-list=list_balance_negative to-addresses=192.168.254.3 to-ports=80

 /ip firewall filter
 add action=accept chain=forward comment=for_site_give_money disabled=no dst-address=192.168.254.3
 add action=accept chain=forward comment=for_site_give_money disabled=no src-address=192.168.254.3

P.S. Если у вас тысячи юзеров и вы раздаете белые адреса, т.е. не юзаете NAT, то для более высокой стабильности работы NAS серверов и снижения нагрузки - лучше вообще отключить conntrack (http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Connection_tracking). Но тогда не будут работать след. фишки (которые нафег не нужно юзать провайдеру на писюках на гигабитных каналах с тысячами юзеров):

NAT
firewall:
 connection-bytes
 connection-mark
 connection-type
 connection-state
 connection-limit
 connection-rate
 layer7-protocol
 p2p
 new-connection-mark
 tarpit
p2p matching in simple queues


Cответственно, раз не будет работать NAT, то и редирект тоже не будет работать. (есть еще Ideco Agent - пользовательское приложение - висит в трее и предупреждает о скором превышении лимита, показывает баланс, расход и прочее).

Другими словами - на писюках нужно использовать минимум извращений. В идеале - если у Вас десятки тысяч клиентов - нужно юзать специализированное оборудование операторского класса (и уж точно не нужно юзать VPN в 21 веке - для "авторизации" доступа в Инет).

[править] Исключить список ресурсов из шейпера

Нет ничего проще.

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

И тупо создаете в мангл-форвард правила - в обе стороны - где в качестве условий выбираются эти листы и действие ACCEPT. Перетаскиваете эти правила вверх (выше правил, где метиться трафик тарифов). И всё - пакеты из этих подсетей "прощелкиваются" и не попадают в правила маркировки - и поэтому не попадают в шейпер.

Никто не мешает для этих ресурсов не просто "прощелкать" тарфик в мангле - а пометить "отдельными метками" и загнать все в свой шейпер. Т.е. по обычной схеме - все как и для тарифов - свои mark в мангл, свои pcq type, свои ветки в QueueTree.

Таким образом можно сделать больше скорость на "городские ресурсы" (пиринговые ресурсы) - чем скорость в Инет

[править] Отдельные шейперы для отдельных ресурсов на разных тарифах

Можной пойти дальше и сделать комбинации - для каждого тарифа - своя скорость не только в Инет - но и на эти "городские ресурсы". Это тоже абсолютно не сложно.

[править] Разрешить список ресурсов для отрицательного баланса

Бывает полезно in real life разрешить "отрицательным" юзерам дать доступ к сайтам платежных систем, банков и прочих сотовых операторов - чтобы они могли спокойно оплатить услуги в субботу ночью не выходя из дома.

Нет вообще ничего проще:

Создаете списки этих адресов - загоняете их ручками в специальный адрес-лист (free_list).

И создаете два правила в форварде - разрешить трафик с/на этот лист. И перетаскиваете эти правила вверх (выше правил, которые блокируют трафик отрицательных юзеров).

Если делаете редирект для отрицательных юзеров как я описывал выше - то добавьте правило-исключение для этих ресурсов (DNAT для листа free_list - действие accept и перетащить вверх)

И всё.

[править] Несколько серверов доступа

Для балансировки нагрузки и резерва и создания избыточной производительности - при условно большом к-ве пользователей - можно использовать несколько серверов доступа.

Настройка дополнительных NASов ничем не отличается от настройки одного (первого NASа).

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

Если используете PPTP/L2TP - то для подключения юзеров используйте всегда доменное имя сервера (а не IP) - и в статических записях днс на микротике - пропишите ip адреса серверов доступа - с одним и тем же доменным именем. Таким образом при резолвинге имени в ip - днс сервер будет выдавать записи циклически и юзеры приблизительно равномерно будут цепляться на NASы. В этом легко убедится - используя утилиту nslookup. Тут важно - чтобы юзеры использовали ваш днс сервис. Обычно он посылается в качестве опции DHCP - 95% юзеров не трогают настройки днс. Те же, кто любит вручную прописывать публичные днс серверы - принципиально не влияют на распределение между NASами.

Если используете IPoE - то один из вариантов - VRRP

Не забывайте добавлять имя и адрес своих НАСов в скрипт обработки событий.

Прочие скрипты/протоколы/алгоритмы резервирования - выходят за рамки данной статьи.

[править] "Строгий managment" (services/users/firewall input)

При использовании схемы в реальной жизни:

  • не забудьте установить сложные пароли
  • в идеале пароли нужно иногда менять )
  • не компрометируйте административные пароли - не вводите их из "публичных" мест, либо сразу потом меняйте.
  • можно/нужно ? установить с каких адресов разрешен доступ для различных служб/портов/сервисов - на трех уровнях: пользователи/службы/фаервол(Input).

[править] Резервный радиус сервер: для случая выхода из строя биллинга (простая лаконичная схема)

Поднимем тему о том, что неплохо бы иметь резервный RADIUS сервер, который в случае серьёзного выхода из строя сервера с биллингом или проведения профилактики, мог бы продолжить авторизовывать юзеров.

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

Некоторые вообще делают минимальную зависимость от биллинга и заводят учетки юзеров параллельно - и на NASе - и в базе Биллинга. Это тоже в принципе рабочая схема. Многие даже написали обвязку симпатишную для автоматизации этого процесса.

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

Поэтому предлагаю резервный план в случае краха биллинга реализовать ПОПРОЩЕ:

Делал на GNU/Linux:

  1. Одной командочкой ставиться из репозитария freeradius - на наш резервный сервер (который может быть очень скромным по железу)
  2. На NASе добавляем в списке радиус серверов - адрес этого резервного сервера (он будет автоматически работать только в случае недоступности первого (основного) в списке).
  3. Юзерам в профиле ppp - заводим и прописываем "резернвый" пул адресов - он заработает, если только радиус сервер перестанет выдавать адреса. Т.е в обычном режиме - если адрес выдал биллинг - он никак не влияет.
    На нашем резервном радиус сервере мы не будем даже БД поднимать и настраивать учетки. ("чем проще - тем лучше").
  4. Для "резервного пула" на NASе заранее настроим правила в мангле и форварде, а также NAT и дефолтный шейпер - как и для обычного любого тарифа. (Скорость указать на выбор исходя из своих реалий - в час Х потом можно будет подкручивать на ходу без разрывов).
  5. В конфиге clients.conf нашего резервного радиуса добавляем наши NASы (IP адреса и радиус секрет) - там есть пример.
  6. В конфигах users нашего резервного радиуса пишем ВСЕГО ОДНУ СТРОЧКУ:
 DEFAULT Auth-Type := Accept

(все остальное - вырезаем)

Что означает ВСЕМ юзерам разрешить авторизоваться с любым паролем и логином в случае краха основного радиус сервера.

Перезапускаем радиус демона.

И это все.

Пару минут времени, пару строчек из букаф.

Итого, что мы имеем?

Все уже настроено, но в обычном режиме никак не влияет ни на что.

В случае выхода из строя сервера с биллингом:

Юзеры, которые уже были подключены на NASы вообще ничего не замечают и продолжают быть в онлайне.

Вновь подключенные юзеры получают дефолтную авторизацию с резервного радиуса и получают адреса из дефолтного пула и натяться дефолтным правилом и шейпяться дефолтным шейпером.

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

При восстановлении биллинга - снова NASы увидят первый (основной) радиус в списке и снова делает запросы уже туда...

И как бы ни единого разрыва )

Достоинства - очень простая реализация автоматического резерва.

Недостатки - не будет собираться статистика в этот период.

P.S. Как показала практика - в реальной жизни бывают ложные срабатывания - т.е. если айдеко радиус притупил на пару сек - то юзер подключается через резервный радиус - что вполне логично. Поэтому я в обычном режиме выключил резервный радиус и резервный пул на NASах. А чтобы не давать полный доступ ко всем NASам - написал скриптик - который заходит на все серверы - включает там резервный радиус, отключает основной, и резервный адрес-лист "включает". И сделал для ночного дежурного "кнопочку" в Zabbix - "резервная схема On" и "резервная схема Off". У дежурного есть инструкция - когда можно эту схему включить (грубо говоря - когда явно будет понятно - что вышел из строя основной радиус сервер - множество звонков от клиентов и т.д.). Но если у Вас нет ночного дежурного - можно все оставить как есть. Либо написать тоже скриптик - который будет анализировать доступность основного радиус сервера и в случае его недоступности N времени - включать на NASах резервную схему и отправлять вам смс или мыло на телефончег - что, мол, "ай-яй-яй" ))) Такие дела.

[править] Послесловие

Вышеописанная схема работает в реальной сети, которая выросла за 5 лет с 20 юзеров до 15 000.

В статье описаны самые основные базовые моменты. Как известно - существует множество решений одной и той же задачи, и множество инструментов. Я описал лишь одную "узкую тропинку". После ваших тренировок на виртуальном стенде и понимания базовых нюансов - вы можете тюнить систему под особенности вашей инфраструктуры.

Как известно - не существует идеальных схем, но существует множество решений, которые имеют свои плюсы и минусы в каждом конкретном случае, взвесив которые, вы можете выбрать решение своих задач.

Прежде чем задавать вопросы на форумах - воспользуйтесь поиском по документации и форумам. Скорее всего ответы уже существуют.

Особую благодарность выражаю своей дочке, которая всячески "помогала" в написании этой статьи. ))))

Права на статью не существуют.

Перепечатка разрешена чуть более, чем полностью.

Автор не несет никакой ответственности ни за что )

Все замечания и предложения. а также сообщения о найденых ашыпках пишите на форум carbonsoft:

http://forum.carbonsoft.ru/viewtopic.php?f=11&t=74&sid=22caa6e8dcfa15368531d604e06fdd9a

Подпись _____________ White_Crow, 12.12.12г от Р.Х.

[править] Примечания