Информация предоставлена White_Crow с ресурса http://xgu.ru/wiki/%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BD%D0%B3_Ideco_%D0%90%D0%A1%D0%A0_%2B_MikroTik_ROS
Упрощенный пример интеграции для версии Ideco АСР >=3.9.7(RAD6) и MikroTik Router OS 5.22 для PPP пользователей
Похоже, что нужно отвыкать от бренда 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)
Установка и первичная настройка
Предполагается, что читатель владеет базовыми понятиями настройки сети и самостоятельно установил данные продукты и имеет доступ к ним с машины администратора.
Для помощи используйте официальную онлайн документацию:
- http://docs.carbonsoft.ru/display/asrdocnew/Home ru — русскоязычная,
- http://wiki.mikrotik.com en — англоязычная, но в инете полно материалов на русском по данному продукту.
Проверьте, что обе системы "видят" друг друга (с помощью банального icmp ping).
Проверьте, что на микротике настроено подключение к вышестоящему провайдеру (интерфейс, маршрут по умолчанию).
И проверьте пингуется ли "мир" с микротика.
После этого можно переходить к следующему разделу.
Лицензии
Для ознакомления с данными программными продуктами существуют полнофункциональные демоверсии, которые можно скачать на официальных сайтах.
Демопериод на продукт 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 сессии если надо и т.д.
При этом Биллинг стоит в сторонке и выполняет следующие функции: учет абонентов в базе данных, авторизация, ведение счетов, тарификация согласно тарифным планам, генерация событий, прием платежей, отчеты, интерфейс для администраторов, кассиров и прочих сотрудников компании. Личный кабинет для пользователей и прочее.
Далее рассмотрим подробней различные аспекты совместной работы двух систем.
Базовая Настройка Ideco АСР
Инструкция актуальна для версии Ideco АСР 3.9.7
На более старых версиях существуют мелкие и боле серьезные отличия, но я не буду их рассматривать.
Просто замечу: я рекомендую использовать для коммерческого использования именно версию 3.9, так как продукт за последний год сильно доработан и улучшен.
Создание пользователя root
Первым делом создайте пользователя ''root''
(по умолчанию суперпользователь отключён).
В официальной документации раздел называется ''Включение постоянного удаленного помощника"''
(не путать с устаревшим разделом: "Создание пользователя root").
Консольное меню
Откройте консольное menu
RADIUS
Настройте [[RADIUS]] сервер таким образом:
''Конфигурирование сервера -> RADIUS-Сервер...''
[x] Включить RADIUS-сервер
[x] Удалять лишние пробелы из логина RADIUS
.
.
.
[x] Использовать процедуры версии 6
NetFlow
''Конфигурирование сервера -> NetFlow коллектор...''
UDP-порт для приема 9996
[x] Приём NetFlow потоков с разных источников
SSH managment
для удаленного входа в консоль биллинга используется протокол [[SSH]]
''Конфигурирование сервера -> Безопасность...''
Поставьте отметку в следующих пунктах:
[x] Разрешить управление файлами по SSH
[x] Разрешить полное удаленное управление по SSH
и пропишите свой ''IP-адрес компьютера администратора'':
Для возможности правки некоторых файлов нужно в локальном меню зайти в пункт ''Сервис'' и нажать на пункт ''"Разрешить запись из [[SFTP]] на раздел с резервными копиями"''.
События и скрипты
В локальном меню проверьте наличие галочки в пункте:
''Конфигурирование сервера -> Дополнительные настройки -> Настройки для разработчиков...''
[x] Запускать скрипт обработки событий
Перезагрузите сервер Ideco корректно из меню:
"Зайдите" на сервер с помощью [[SFTP]] на порт 33 под учетной записью root.
(если вы админите из-под венды 
- то один из популярных клиентов - это WinSCP)
Я в линухе "из коробки" ввожу прямо так:
Перейдите в директорию <tt>/var/lib/event/</tt>
Откройте на редактирование файл <tt>event_inc.sh</tt>
Выделите все и удалите. Затем вставьте следующее:
LOG_LEVEL=ALL 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 [ "$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 [ "$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
'''Важно!!!''' Если в венде это делаете - Файл должен содержать 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:'''
#!/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 права.
Manager
Интерфейс управления Ideco Manager написан и скомпилирован под венду, но в wine работает без вопросов.
Общие настройки
''Сервис -> Настройки''
Таймаут accounting update - данную переменную можете ставить сутки (в секундах, ессно).
Оборудование
Добавим параметры нашего NASа по примеру:
Пулы
Добавляете пул адресов, которые через RADIUS будут выдаваться юзерам в VPN тунели
(не имеет значения - белые адреса, либо серые).
Позже также мы рассмотрим варианты с "динамическими" и "статическими" адресами, а также нюансы с белыми и серыми адресами, и варианты без VPN тунелей и использование DHCP.
Базовая настройка MikroTik ROS
Identity
Как уже упоминалось ранее - имя вашего сервера Микротик нельзя менять от балды, по дефолту пропишите
в разделе ''System -> Identity'' : ''nas1''
5b0b2b6aa11b.png!
Clock
Нужно настроить время на NASе для нормальной работы и логов.
Пропишите ближайшие к Вам два надежных сервера NTP.
Telnet group/user
В биллинге автоматически выполняются скрипты по различным событиям и производят определенные манипуляции на сервере NAS через telnet.
Ка уже выше писалось - я просил записать на бумажку имя телнет юзера user2 и придуманный вами пароль, который вы ранее прописали в скриптах обработки событий.
Пришло время настроить специальную группу и этого юзера на Микротике:
Открывайте в winbox меню: ''System -> Users''
и там щелкаете по вкладке ''Groups''
Затем на плюс (добавить новую группу).
Придумайте имя группы (например telnet)
Расставьте галочки напротив следующих прав:
- write
- test
- telnet
- read
нажмите Ok.
Далее жмите вкладку ''Users''.
Добавляйте нового юзера с именем user2 и выбирите из нисподающего списка имя вышесозданной группы.
Обязательно укажите, что доступ этому юзеру разрешен только с IP адреса биллинга - в поле Allowed Address: укажите IP адрес вашего билинга.
Укажите и подтвердите пароль созданного юзера ''user2'' (тот, что я просил выше придумать вместо YOUR_TELNET_PASSWD и записать на бумажке)
DNS
Для корректной работы интернет сервисов необходимо настроить службу [[DNS]].
Схема такая - на Микротике включаем кеширующий днс. Указываем ему несколько надежных днс служб - обычно используются серверы вышестоящего провайдера (Не рекомендую более двух серверов указывать). И нашим юзерам, например с помощью опции DHCP - передаем в качестве днс сервера - локальный адрес NAS сервера. Таким образом юзер делает днс запросы на Микротик сервер, если у него в кеше нету такой записи, то микротик делает запрос в прописанные "вышестоящие" днс серверы, и затем возвращает ответ нашим юзерам. Все это происходит обычно быстрее, чем вы читаете этот абзац )))))
DHCP
Если Вы используете DHCP на NASе, то отключите его в биллинге.
Запустите мастера настройки DHCP сервера на Микротике.
Подробно пока не буду заострять внимания на этих банальных настройках - в Сети множество примеров.
Лишь некоторые очевидные нюансики:
Юзеры должны находится в одном сегменте с сервером [[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 сервер в биллинге:
Далее настройте профиль default:
и
Затем включите радиус аутентификацию и аккаунтинг, и создайте ppp секрет, при этом выбирите из нисподающего списка нужный Вам Service:
Включаем PPPoE сервис на локальном интерфейсе с профилем default:
Если вместо PPPoE решили юзать PPTP или L2TP - включите нужный Вам сервис:
Traffic Flow
Для подсчета объемов трафика и сбора подробной статистики нужно отсылать биллингу инфу о проходящем сквозь NAS трафике юзеров:
Включите traffic flow, выбирите все интерфейсы (all) и укажите куда отсылать netflow v5 - адрес вашего биллинга.
Radius Accounting
Я лично отсылаю netflow версии 9 не на биллинг, а на отдельный сервер. (для справки - я юзаю debian + nfdump + nfsen). А объемы трафика у меня в биллинге считаются не с помощью netflow, а с помощью Radius протокола.
Это нужно, когда у вас десятки тысяч юзеров и гигабиты трафика в секунду - чтобы не напрягать биллинг. Таким образом легко можно масштабировать [[NetFlow]] коллекторы - например условно на каждых 5 NASов - свой нетфлоу коллектор.
Минус такого метода один - с помощью радиуса мы можем считать только объемы, но биллинг ничего не будет знать об посещаемых IP адресах, а значит не сможем сделать в помегабайтных тарифах - льготные или бесплатные ресурсы. Но в век безлимитов этот нюанс имеет все меньше и меньше значения. Сейчас "льготность" может заключаться в бОльших скоростях на льготные ресурсы - о чем мы поговорим позже.
Еще одно замечание - по умолчанию NAS скидывает промежуточную информацию (Radius Accounting) на биллинг каждые 300 сек. Если юзеров очень много (тысячи их) - есть смысл это время увеличить. Для этого нужно в биллинге в манагере в настройках каждого тарифа - > во вкладке RADIUS - добавить такой атрибут:
Acct-Interim-Interval := 2400
(важно - в общих настройках в манагере '' радиус аккаунтинг таймаут'' должен быть больше чем Acct-Interim-Interval, и как я уже выше советовал - ставьте таймаут сутки)
RADIUS
Включаем radius пока только для VPN (ppp), позже рассмотрим работу radius + DHCP и + Hotspot
Прописываем адрес биллинга. И указываем ваш радиус секрет (тот, который вы придумали YOUR_RADIUS_SECRET)
Тарифы. Ideco
Рассмотрим четыре базовых тарифа и "турбокнопку".
Пронумеруем для удобства эти сущности.
Прежде чем создать тарифы - создайте в Ideco Manager "правила и сети". А лучше воспользуйтесь заготовками, которые есть в базе данных для примера. И не забывайте про онлайн документацию.
Простой безлимит (№1)
Пусть вас не смущает, что я написал скорость "1". Это не килобиты в данном случае, а номер, который будет передаваться в Микротик. Есть лицензия на Ideco - которая позволяет обойтись без использования NAS и пропускать трафик через сервер биллинга - в этом случае тут пишутся реальные скорости в килобитах для шейпера Ideco SoftRouter. В нашем случае трафик идет не через Ideco, а через Микротик - там мы и будем позже настраивать шейпер.
Не забудьте поставить галочку "блокировать при превышении лимита".
Не забудьте указать абонентскую плату.
note|text=В описываемой мной схеме - RADIUS атрибуты в тарифе прописывать не нужно!!!
Условный безлимит (скорость зависит от объема)(№2)
До 200 Гигов входящего объема - скорость номер 2
После 200 Гигов входящего объема - скорость номер 22 - до конца месяца.
"Помегабайтный" (цена зависит от объема) (№3)
Тут никто не мешает добавить других правил и подсетей с другой стоимостью мегабайтов.
И никто не мешает указать разную стоимость трафика для разных объемов, времени суток, и для входящего и исходящего - раздельно.
Безлимит - разная скорость в разное время суток (№4)
{{note|text=Внимание! Мы будем менять скорость в разное время суток для этого тарифа - на Микротике (об этом позже).
Поэтому тут в Ideco не нужно указывать время и скорость.}}
Турбокнопка (№5)
Укажите стоимость услуги, номер скорости, время действия турбо-режима, и разрешите заказ через веб кабинет.
Важно: Во всех тарифах отключите "Разрешить все услуги с флагом "заказ через Web" и явно добавьте в каждый тариф нужные услуги, в том числе и турбокнопки, коих можно создать неограниченное к-во с разными параметрами цены. скорости и времени действия.
Настройка группы и "карточки" юзера
Создайте группу по примеру:
Cоздайте юзеров по примеру:
''Комментарии:''
Не используйте заглавные буквы, кирилицу, пробелы в логинах юзеров!!!
Уберите галочку isNAT - даже если Вам нужен NAT - мы его настроим позже на Микротике.
Внимательно с признаком "финансовый" и "порогом отключения" и "периодом формирования акта" (варианты использования - в официальной документации)
Тарифы. MikroTik
Дерево очередей. Родители.
Переходим к так называемому шейперу.
Кого интересует теория - можно немного почитать 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
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
В итоге должно получится вот так:
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
В итоге должно получиться так:
И как я говорил выше - можно в любой момент тюнить скорость без всяких разрывов, меняя параметр 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
В итоге получаем окончательный шейпер (дерево очередей) для наших тарифов и турбокнопки:
Расписание изменения скорости для тарифа №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)
В итоге получаем:
Тарифы и 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.
Другими словами - когда клиент делает 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 - точно не помню - попробуйте оба варианта).
Недостатки схемы те же, что и в предыдущем случае. К тому же - в ideco нужно правильно "разбирать" поля опции82 - так как они для разных вендоров разные - тоже из коробки не будет работать пока-что. Если кому сильно надо - нужно обращаться к разработчкиам - '''они подпилят'''. (Конечно, если у Вас не бесплатная лицензия, поддержка на которую не оказывается). Хотя на демо версию - поддержка есть. И если Вы убедите их - что Вы - потенциальный клиент - собрались купить лицензию, и лишь "вот этот вот нюанс" вас останавливает ....)))
WiFi и HotSpot: Web авторизация + CHAP + Radius
Данная схема абсолютно рабочая и кошерная.
Позиционируется для настройки беспроводных точек доступа Микротик и беспроводных клиентов (аля смартфоны/нетбуки/планшеты - в гостиницах, общагах, библиотеках и прочих аэропортах.
В данном случае от биллинга не потребуется абсолютно никаких особенных настроек - т.е. делаете все по инструкции выше. В том числе и скрипт обработки событий является универсальным.
Расставляем точки доступа Микротик. Настраиваем их в биллинге как и "обычные" NAS Микротик.
С той лишь разницей - на точках доступа используется не VPN, а HOTSPOT - в котором есть полноценный RADIUS c аккаунтингом:
Включаем Web авторизацию + CHAP:
Dba8e01fd594.png!
В итоге в браузере клиента появится окошко, где нужно вводить имя и пароль. Эту страничку можно разукрасить как угодно. И добавить разных ссылок и полезных каментов и объясняшек и т.д.
Также можно указать сайты, которые могут быть доступны без авторизации (Walled Garden).
В Сети легко находятся примеры настройки MikroTik HotSpot и Wireless.
Плюсы - юзерам со смартфонами не нужно (не возможно) возиться с тунелями - вместо этого есть понятное окошко веб-авторизации.
Минусы - нету. (просто нужно понимать нишу - для которой эту схему нужно юзать)
Кстати - HotSpot работает не только на беспроводном фейсе, но и вполне себе на Ethernet интерфейсах. О чем ниже...
WiFi и Ethernet HotSpot: MAC+Radius
Можно использовать авторизацию по MAC адресу.
!!! При этом, напоминаю, HotSpot не только для беспроводной сети - он отлично работает и на ethernet интерфейсах. И если веб авторизация явно предназначена для беcпроводных клиентов в лице разных мобилок и прочих девайсов аля планшетики, то хотспот + MAC авторизация - вполне органично может использоваться в Ethernet сети для проводных клиентов.
На ideco соответственно вместо имени и chap пароля юзера - проверяется только MAC адрес юзера и общий пароль. (на скрине выше заполните поле MAC Auth. Password ), и пропишите этот "общий" радиус пароль в Ideco Manager - в св-вах соответсвующего NASa ("оборудование" - "маршрутизаторы" - ... выбираем NAS ... - "USERS_PSW" ):
передается заглавными символами. По-поводу дефисов и двоеточий - выбирайте шаблон в Тике в ниспадающем списке "MAC Format" ("IP - Hotspot - Radius"):
!!! Внимание - вписывайте MAC в поле "Логин" - в карточке юзера в Ideco менеджере.
!!! Нужно отключить фишку на Ideco, которая режет пробелы и заглавные символы в радиус запросах (да - таки эта фишка кроме пробелов еще режет символы A-Z - чуть ниже расскажу зачем вообще она нужна):
(кстати - никто не мешает редактировать и тюнить на 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 - ничем не отличаются:
(пусть вас не смущают галочки "лишние" - это для универсальности: VPN + radius и схема IPoE без радиус могут работать одновременно!). Понятно, что радиус и впн можно и не настраивать - IPoE все равно будет работать!
Особенности:
В этой схеме - юзеру выставляется тип "авторизации по IP".
Так как приходится обходится без радиуса - то биллинг ни черта не в курсе через какой NAS там форвардится юзерский траф - поэтому в "карточке" клиента нужно прописать NAS IP и залочить галочку.
Недостаток схемы - из-за отсутствия радиуса - нет фактического логина/логаута - нет постоянной "актуализации" в каком листе юзер должен находится. Событие "логин" происходит формально один раз. Юзер как бы подключен всегда - нет явных сессий по факту. Трафик рулиться с помощью редких событий - баланс негатив и позитив (так как юзеры платят сразу на неделю или даже месяц). В итоге может происходит "рассинхрон" между биллингом и 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 и перетащить вверх)
И всё.
Несколько серверов доступа
Для балансировки нагрузки и резерва и создания избыточной производительности - при условно большом к-ве пользователей - можно использовать несколько серверов доступа.
Если используете PPPoE - то в общем случае никаких дополнительных манипуляций не потребуется - юзеры будут статистически равномерно цепляться на серверы, т.к. ищут сервер с помощью броадкаста - и подключаются на первый ответивший сервер - а серверы не могут всегда одинаково отвечать до тысячной доли секунды...
Если используете PPTP/L2TP - то для подключения юзеров используйте всегда доменное имя сервера (а не IP) - и в статических записях днс на микротике - пропишите ip адреса серверов доступа - с одним и тем же доменным именем. Таким образом при резолвинге имени в ip - днс сервер будет выдавать записи циклически и юзеры приблизительно равномерно будут цепляться на NASы. В этом легко убедится - используя утилиту nslookup.
Тут важно - чтобы юзеры использовали ваш днс сервис. Обычно он посылается в качестве опции DHCP - 95% юзеров не трогают настройки днс. Те же, кто любит вручную прописывать публичные днс серверы - принципиально не влияют на распределение между NASами.
Если используете IPoE - то один из вариантов - [[VRRP]]
Не забывайте добавлять имя и адрес своих НАСов в скрипт обработки событий.
Прочие скрипты/протоколы/алгоритмы резервирования - выходят за рамки данной статьи.
"Строгий managment" (services/users/firewall input)
При использовании схемы в реальной жизни:
- не забудьте установить сложные пароли
- в идеале пароли нужно иногда менять )
- не компрометируйте административные пароли - не вводите их из "публичных" мест, либо сразу потом меняйте.
- можно/нужно ? установить с каких адресов разрешен доступ для различных служб/портов/сервисов - на трех уровнях: пользователи/службы/фаервол(Input).
Резервный радиус сервер: для случая выхода из строя биллинга (простая лаконичная схема)
Поднимем тему о том, что неплохо бы иметь резервный 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ах резервную схему и отправлять вам смс или мыло на телефончег - что, мол, "ай-яй-яй" )))
Такие дела.
Послесловие
Вышеописанная схема работает в реальной сети, которая выросла за 5 лет с 20 юзеров до 15 000.
В статье описаны самые основные базовые моменты. Как известно - существует множество решений одной и той же задачи, и множество инструментов. Я описал лишь одную "узкую тропинку". После ваших тренировок на виртуальном стенде и понимания базовых нюансов - вы можете тюнить систему под особенности вашей инфраструктуры.
Как известно - не существует идеальных схем, но существует множество решений, которые имеют свои плюсы и минусы в каждом конкретном случае, взвесив которые, вы можете выбрать решение своих задач.
Прежде чем задавать вопросы на форумах - воспользуйтесь поиском по документации и форумам. Скорее всего ответы уже существуют.
Особую благодарность выражаю своей дочке, которая всячески "помогала" в написании этой статьи. ))))
Права на статью не существуют.
Перепечатка разрешена чуть более, чем полностью.
Автор не несет никакой ответственности ни за что )
Все замечания и предложения. а также сообщения о найденых ашыпках пишите на форум carbonsoft:
http://forum3.carbonsoft.ru/forum3/default.aspx?g=posts&t=4850