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

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

h2. Введение

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

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

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

* [http://www.carbonsoft.ru]
* [http://mikrotik.com]

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

h2. Установка и первичная настройка

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

* [http://docs.carbonsoft.ru/display/asrdocnew/Home] {{ru}} --- русскоязычная,
* [http://wiki.mikrotik.com] {{en}} --- англоязычная, но в инете полно материалов на русском по данному продукту.

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

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

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

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

h2. Лицензии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

h2. Базовая Настройка Ideco АСР

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

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

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

h3. Создание пользователя root

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

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

h3. Консольное меню

.
.

h3.

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

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

h4. SSH managment


h3.

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

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

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

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

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

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

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

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

;;

;;
##################################################################################################
"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
;;

else
/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
fi
;;

;;
##################################################################################################
*)
:
;;
esac
{code}
'''Важно\!\!\!''' Если в венде это делаете - Файл должен содержать unix символы окончания строки.
(если не знаете, что это такое, и как в венде в разных текстовых редакторах выбрать тип окончания строки...погуглите (если, конечно, в "вашей стране" еще не закрыли доступ в гугл ))).



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

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

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

'''event1.sh:'''

{code}
#!/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
{code}

'''event2.sh:'''

{code}
#!/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
{code}

'''event3.sh:'''

{code}
#!/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
{code}

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

h3. Manager

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

h4. Общие настройки


h3.

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

!E5be392f8822.png!

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

h4. Оборудование


h3.

h3.

Добавляете пул адресов, которые через RADIUS будут выдаваться юзерам в VPN тунели

h3. Identity

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

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

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

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

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

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

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

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

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

- write
- test
- telnet
- read

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

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

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

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

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

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

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

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

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

h3. VPN (secret/profile/radius)

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

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

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

h3. Radius Accounting

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

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

h3. RADIUS

h2. Тарифы. Ideco

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

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

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

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

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

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

Поэтому тут в Ideco не нужно указывать время и скорость.}}

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

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

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

h2. Тарифы. MikroTik

h3. Дерево очередей. Родители.

Переходим к так называемому шейперу.
Кого интересует теория - можно немного почитать [http://wiki.mikrotik.com/images/8/8d/QoS_Megis_%28Russian_translate_by_white_crow_rev.2%29.pdf тут] мой перевод одной презентации (\[[Media:QoS Megis (Russian translate by white crow rev.2).pdf|скачать]\])

(кстати позже оказалось, что там есть ошибочки, которые перетекли и в мой перевод, но есть более свежая переработанная презентация ([http://mum.mikrotik.com/presentations/US11/us11-megis.pdf] {{en}})

Итак:

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

Методом "копипасты" вставляйте в 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

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

Для тарифа №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

В итоге скорость содержится в значении параметра 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

h3. Создание листьев в дереве очередей

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

/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

h3. Расписание изменения скорости для тарифа №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)

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

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

/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

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

h2. NAT

Если Вы раздаете юзерам серые адреса и у Вас на внешнем фейсе в Микротике один белый (реальный) адрес - не забудьте настроить маскарадинг. В самом простом случае:
/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1-Ext

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

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


h2. Динамическая раздача IP адресов

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

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

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

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

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

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

h2. IPoE авторизация

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

Что такое IPoE?

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

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

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


h3. IPoE с Radius


h4. DHCP Mikrotik + MAC + Radius

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

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

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

h3. DHCP Mikrotik + Opt.82 + Radius

h3. WiFi и HotSpot: Web авторизация + CHAP + Radius

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

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

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

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

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

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

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

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


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

h4. WiFi и Ethernet HotSpot: MAC+Radius

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

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

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

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

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

Итоги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и т.д.

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

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

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

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

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

\-IP NAS прописать и залочить

\-поставить ip авторизацию

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

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

h2. Разное


h3. Редирект отрицательный баланс

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 веке - для "авторизации" доступа в Инет).

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

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

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

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

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

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

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

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

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

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

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

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

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

И всё.

h3. Несколько серверов доступа

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

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

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

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

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

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

h3. "Строгий managment" (services/users/firewall input)

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

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

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

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

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

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

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

Делал на GNU/Linux:

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

DEFAULT Auth-Type := Accept

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

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

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

И это все.

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

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

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

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

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

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

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

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

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

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

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

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

h2. Послесловие

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

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

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

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

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

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

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

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

[http://forum3.carbonsoft.ru/forum3/default.aspx?g=posts&t=4850]