|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Комментарий:
Изменения (5)
просмотр истории страницы... Информация предоставлена 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|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] |
| |
| |
| h2. Упрощенный пример интеграции для версии 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 пользователей. 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 ® --- в том числе и с бесплатной лицензией, о чем можно подробней прочитать на официальном сайте. h2. Базовая Схема. Краткое описание !Cd7c181c87bf.png! Понятия: * 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. Консольное меню Откройте консольное menu !Файл:0f4d8356d57d.png! h4. RADIUS Настройте \[[RADIUS]\] сервер таким образом: ''Конфигурирование сервера \-> RADIUS-Сервер...'' [x] Включить RADIUS-сервер [x] Удалять лишние пробелы из логина RADIUS . . . [x] Использовать процедуры версии 6 h4. NetFlow h3. ''Конфигурирование сервера \-> NetFlow коллектор...'' UDP-порт для приема 9996 [x] Приём NetFlow потоков с разных источников h4. SSH managment h3. для удаленного входа в консоль биллинга используется протокол \[[SSH]\] ''Конфигурирование сервера \-> Безопасность...'' Поставьте отметку в следующих пунктах: [x] Разрешить управление файлами по SSH [x] Разрешить полное удаленное управление по SSH и пропишите свой ''IP-адрес компьютера администратора'': !0cf1dda0db01.png! Для возможности правки некоторых файлов нужно в локальном меню зайти в пункт ''Сервис'' и нажать на пункт ''"Разрешить запись из \[[SFTP|WinSCP]\] на раздел с резервными копиями"''. !e3bd87c5c3c1.png! h4. События и скрипты В локальном меню проверьте наличие галочки в пункте: ''Конфигурирование сервера \-> Дополнительные настройки \-> Настройки для разработчиков...'' [x] Запускать скрипт обработки событий !3e513a6fffa1.png! Перезагрузите сервер Ideco корректно из меню: !699cbf874a8a.png! "Зайдите" на сервер с помощью \[[SFTP]\] на порт 33 под учетной записью root. (если вы админите из-под венды :-) \- то один из популярных клиентов - это WinSCP) Я в линухе "из коробки" ввожу прямо так: !E394e1c7e08e.png! Перейдите в директорию <tt>/var/lib/event/</tt> Откройте на редактирование файл <tt>event_inc.sh</tt> Выделите все и удалите. Затем вставьте следующее: {code} 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 [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then |
| /usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi |
... ;; |
| ################################################################################################## "balance_positive") |
| if [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then |
| /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out fi |
... ;; ################################################################################################## "rad_acc_start") if [ "$nas_ip" != "0.0.0.0" ]; then if [ "$over_limit" = "0" ]; then /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out else /usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi fi ;; ################################################################################################## "rate_set") if [ "$logged" = "1" -a "$nas_ip" != "0.0.0.0" -a "$over_limit" = "0" ] ; then /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out fi ;; ################################################################################################## user_data_changed|user_data_changed_before) if [ "$nas_ip" != "0.0.0.0" ]; then echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi ;; ################################################################################################## "radius_update_err") if [ "$nas_ip" != "0.0.0.0" ]; then echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi ;; ################################################################################################## user_disconnect|get_info_fail|rad_acc_timeout) if [ "$nas_ip" != "0.0.0.0" ]; then echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi ;; ################################################################################################## "rad_acc_stop") if [ "$nas_ip" != "0.0.0.0" ]; then /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi ;; ################################################################################################## "try_double_login") if [ "$nas_ip" != "0.0.0.0" ]; then echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi ;; |
| ################################################################################################## "login") #Only for IP_auth |
| if [ "$nas_ip" != "0.0.0.0" -a "$auth_type" = 1 ]; then |
| if [ "$over_limit" = "0" ]; then /usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out |
... else /usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi fi ;; |
| ################################################################################################## "logout") #Only for IP_auth |
| if [ "$nas_ip" != "0.0.0.0" -a "$auth_type" = 1 ]; then |
| /usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity fi |
... ;; ################################################################################################## *) : ;; esac {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. Добавим параметры нашего NASа по примеру: !61eea54a757d.png! h4. Пулы h3. Добавляете пул адресов, которые через RADIUS будут выдаваться юзерам в VPN тунели (не имеет значения - белые адреса, либо серые). Позже также мы рассмотрим варианты с "динамическими" и "статическими" адресами, а также нюансы с белыми и серыми адресами, и варианты без VPN тунелей и использование DHCP. !2ec78ce4ddc5.png! h2. Базовая настройка MikroTik ROS h3. Identity Как уже упоминалось ранее - имя вашего сервера Микротик нельзя менять от балды, по дефолту пропишите в разделе ''System \-> Identity'' : ''nas1'' 5b0b2b6aa11b.png\! h3. Clock Нужно настроить время на NASе для нормальной работы и логов. Пропишите ближайшие к Вам два надежных сервера NTP. !5b2cb3dfe4a1.png! h3. Telnet group/user В биллинге автоматически выполняются скрипты по различным событиям и производят определенные манипуляции на сервере NAS через telnet. Ка уже выше писалось - я просил записать на бумажку имя телнет юзера user2 и придуманный вами пароль, который вы ранее прописали в скриптах обработки событий. Пришло время настроить специальную группу и этого юзера на Микротике: Открывайте в winbox меню: ''System \-> Users'' и там щелкаете по вкладке ''Groups'' Затем на плюс (добавить новую группу). Придумайте имя группы (например telnet) Расставьте галочки напротив следующих прав: - write - test - telnet - read нажмите Ok. !D3b988179489.png! Далее жмите вкладку ''Users''. Добавляйте нового юзера с именем user2 и выбирите из нисподающего списка имя вышесозданной группы. Обязательно укажите, что доступ этому юзеру разрешен только с IP адреса биллинга - в поле Allowed Address: укажите IP адрес вашего билинга. Укажите и подтвердите пароль созданного юзера ''user2'' (тот, что я просил выше придумать вместо YOUR_TELNET_PASSWD и записать на бумажке) !Файл:6995efa7efae.png! h3. DNS Для корректной работы интернет сервисов необходимо настроить службу \[[DNS]\]. Схема такая - на Микротике включаем кеширующий днс. Указываем ему несколько надежных днс служб - обычно используются серверы вышестоящего провайдера (Не рекомендую более двух серверов указывать). И нашим юзерам, например с помощью опции DHCP - передаем в качестве днс сервера - локальный адрес NAS сервера. Таким образом юзер делает днс запросы на Микротик сервер, если у него в кеше нету такой записи, то микротик делает запрос в прописанные "вышестоящие" днс серверы, и затем возвращает ответ нашим юзерам. Все это происходит обычно быстрее, чем вы читаете этот абзац ))))) !Файл:E8139d99b8af.png! h3. DHCP Если Вы используете DHCP на NASе, то отключите его в биллинге. Запустите мастера настройки DHCP сервера на Микротике. !F6a4a1263577.png! Подробно пока не буду заострять внимания на этих банальных настройках - в Сети множество примеров. Лишь некоторые очевидные нюансики: Юзеры должны находится в одном сегменте с сервером \[[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оE - отключите PPPoE сервер в биллинге: !Файл:1484afa87036.png! Далее настройте профиль default: !798feb700475.png! и !De78a5f63cfd.png! Затем включите радиус аутентификацию и аккаунтинг, и создайте ppp секрет, при этом выбирите из нисподающего списка нужный Вам Service: !Ebfff5a9b21d.png! Включаем PPPoE сервис на локальном интерфейсе с профилем default: !08274ccdb2f6.png! Если вместо PPPoE решили юзать PPTP или L2TP - включите нужный Вам сервис: !84cef8874df8.png! h3. Traffic Flow Для подсчета объемов трафика и сбора подробной статистики нужно отсылать биллингу инфу о проходящем сквозь NAS трафике юзеров: !0356d6ff15f4.png! Включите traffic flow, выбирите все интерфейсы (all) и укажите куда отсылать netflow v5 - адрес вашего биллинга. h3. Radius Accounting Я лично отсылаю netflow версии 9 не на биллинг, а на отдельный сервер. (для справки - я юзаю debian + nfdump + nfsen). А объемы трафика у меня в биллинге считаются не с помощью netflow, а с помощью Radius протокола. !F118f4e0c220.png! Это нужно, когда у вас десятки тысяч юзеров и гигабиты трафика в секунду - чтобы не напрягать биллинг. Таким образом легко можно масштабировать \[[NetFlow]\] коллекторы - например условно на каждых 5 NASов - свой нетфлоу коллектор. Минус такого метода один - с помощью радиуса мы можем считать только объемы, но биллинг ничего не будет знать об посещаемых IP адресах, а значит не сможем сделать в помегабайтных тарифах - льготные или бесплатные ресурсы. Но в век безлимитов этот нюанс имеет все меньше и меньше значения. Сейчас "льготность" может заключаться в бОльших скоростях на льготные ресурсы - о чем мы поговорим позже. Еще одно замечание - по умолчанию NAS скидывает промежуточную информацию (Radius Accounting) на биллинг каждые 300 сек. Если юзеров очень много (тысячи их) - есть смысл это время увеличить. Для этого нужно в биллинге в манагере в настройках каждого тарифа - > во вкладке RADIUS - добавить такой атрибут: Acct-Interim-Interval := 2400 (важно - в общих настройках в манагере '' радиус аккаунтинг таймаут'' должен быть больше чем Acct-Interim-Interval, и как я уже выше советовал - ставьте таймаут сутки) h3. RADIUS Включаем radius пока только для VPN (ppp), позже рассмотрим работу radius + DHCP и + Hotspot !Eae38e5b953f.png! Прописываем адрес биллинга. И указываем ваш радиус секрет (тот, который вы придумали YOUR_RADIUS_SECRET) h2. Тарифы. Ideco Рассмотрим четыре базовых тарифа и "турбокнопку". Пронумеруем для удобства эти сущности. Прежде чем создать тарифы - создайте в Ideco Manager "правила и сети". А лучше воспользуйтесь заготовками, которые есть в базе данных для примера. И не забывайте про онлайн документацию. h3. Простой безлимит (№1) !Dd19953e602e.png! Пусть вас не смущает, что я написал скорость "1". Это не килобиты в данном случае, а номер, который будет передаваться в Микротик. Есть лицензия на Ideco - которая позволяет обойтись без использования NAS и пропускать трафик через сервер биллинга - в этом случае тут пишутся реальные скорости в килобитах для шейпера Ideco SoftRouter. В нашем случае трафик идет не через Ideco, а через Микротик - там мы и будем позже настраивать шейпер. Не забудьте поставить галочку "блокировать при превышении лимита". Не забудьте указать абонентскую плату. {{note\|text=В описываемой мной схеме - RADIUS атрибуты в тарифе прописывать не нужно\!\!\!}} !7a88f3b62132.png! h3. Условный безлимит (скорость зависит от объема)(№2) !Ed8c10cee402.png! До 200 Гигов входящего объема - скорость номер 2 !A85365aa5229.png! После 200 Гигов входящего объема - скорость номер 22 - до конца месяца. !35f51c301cb9.png! h3. "Помегабайтный" (цена зависит от объема) (№3) !Ed0a1a7fc802.png! Тут никто не мешает добавить других правил и подсетей с другой стоимостью мегабайтов. И никто не мешает указать разную стоимость трафика для разных объемов, времени суток, и для входящего и исходящего - раздельно. h3. Безлимит - разная скорость в разное время суток (№4) !D1fbdc2856dc.png! {{note\|text=Внимание\! Мы будем менять скорость в разное время суток для этого тарифа - на Микротике (об этом позже). Поэтому тут в Ideco не нужно указывать время и скорость.}} h3. Турбокнопка (№5) !4657a9a9e7e0.png! Укажите стоимость услуги, номер скорости, время действия турбо-режима, и разрешите заказ через веб кабинет. Важно: Во всех тарифах отключите "Разрешить все услуги с флагом "заказ через Web" и явно добавьте в каждый тариф нужные услуги, в том числе и турбокнопки, коих можно создать неограниченное к-во с разными параметрами цены. скорости и времени действия. !37d92db5de90.png! h3. Настройка группы и "карточки" юзера Создайте группу по примеру: !277309f71e9a.png! Cоздайте юзеров по примеру: !4f19a5fd80fa.png! ''Комментарии:'' Не используйте заглавные буквы, кирилицу, пробелы в логинах юзеров\!\!\! Уберите галочку 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 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 h3. Маркировка трафика в Mangle Итак, настроим маркировку трафика в двух направлениях (download/upload) для наших четрыех тарифов и турбокнопки: Копипастим в терминал: Для тарифа №1 /ip firewall mangle add action=mark-packet chain=forward comment=list_1_1_up disabled=no new-packet-mark=mark_1_up passthrough=no src-address-list=list_1_1 add action=mark-packet chain=forward comment=list_1_1_down disabled=no dst-address-list=list_1_1 new-packet-mark=mark_1_down passthrough=no Для тарифа №2 правило до 200 гигов /ip firewall mangle add action=mark-packet chain=forward comment=list_2_2_up disabled=no new-packet-mark=mark_2_up passthrough=no src-address-list=list_2_2 add action=mark-packet chain=forward comment=list_2_2_down disabled=no dst-address-list=list_2_2 new-packet-mark=mark_2_down passthrough=no правило после 200 гигов /ip firewall mangle add action=mark-packet chain=forward comment=list_22_22_up disabled=no new-packet-mark=mark_22_up passthrough=no src-address-list=list_22_22 add action=mark-packet chain=forward comment=list_22_22_down disabled=no dst-address-list=list_22_22 new-packet-mark=mark_22_down passthrough=no Для тарифа №3 /ip firewall mangle add action=mark-packet chain=forward comment=list_3_3_up disabled=no new-packet-mark=mark_3_up passthrough=no src-address-list=list_3_3 add action=mark-packet chain=forward comment=list_3_3_down disabled=no dst-address-list=list_3_3 new-packet-mark=mark_3_down passthrough=no Для тарифа №4 /ip firewall mangle add action=mark-packet chain=forward comment=list_4_4_up disabled=no new-packet-mark=mark_4_up passthrough=no src-address-list=list_4_4 add action=mark-packet chain=forward comment=list_4_4_down disabled=no dst-address-list=list_4_4 new-packet-mark=mark_4_down passthrough=no Для нашей турбокнопки: /ip firewall mangle add action=mark-packet chain=forward comment=list_5_5_up disabled=no new-packet-mark=mark_5_up passthrough=no src-address-list=list_5_5 add action=mark-packet chain=forward comment=list_5_5_down disabled=no dst-address-list=list_5_5 new-packet-mark=mark_5_down passthrough=no В итоге должно получится вот так: !744d9be53f95.png! h3. Cоздание типов очередей PCQ В итоге скорость содержится в значении параметра pcq-rate= Т.е. для первого тарифа сделаем для примера скорость 20M/10M В итоге потом можно в любое время эту скорость менять даже на ходу. При этом юзеры даже не заметят - обрыва не будет - ни VPN сессии, ни TCP/UDP/GRE соединений. Теперь понимаете, почему в настройках тарифов в Ideco Manager я писал именно номера, вместо скорости в килобитах? Для гибкости. Можно было сразу там писать скорость, и потом во всех правилах тоже, но тогда при смене скорости тарифа - везде надо было эти цифры менять, а так только парметр pcq-rate= в WinBox на ходу меняем при необходимости - и всё. Итак Для тарифа №1 - скорость 20M/10M /queue type add kind=pcq name=pcq_1_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=20M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_1_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=10M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 Для тарифа №2 Сделаем для примера скорость 20M/10M для объема до 200 гигов /queue type add kind=pcq name=pcq_2_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=20M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_2_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=10M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 и сделаем скорость 512k/512k для объема после 200 гигов /queue type add kind=pcq name=pcq_22_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_22_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=512k pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 Для тарифа №3 Сделаем для примера скорость 30M/30M /queue type add kind=pcq name=pcq_3_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=30M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_3_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=30M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 Для тарифа №4 Сделаем для примера скорость 2M/2M в дневное время (планировщик, который меняет скорость в ночное время на 50M/50M сделаем чуть позже) /queue type add kind=pcq name=pcq_4_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=2M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_4_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=2M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 Для нашей турбокнопки сделаем скорость 90M/90M: /queue type add kind=pcq name=pcq_5_down pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=90M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 add kind=pcq name=pcq_5_up pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=src-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=90M pcq-src-address-mask=32 pcq-src-address6-mask=64 \ pcq-total-limit=64000 В итоге должно получиться так: !936279405a39.png! И как я говорил выше - можно в любой момент тюнить скорость без всяких разрывов, меняя параметр pcq-rate= 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 В итоге получаем окончательный шейпер (дерево очередей) для наших тарифов и турбокнопки: !45e6851bbfec.png! 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) В итоге получаем: !5d7869d4edbb.png! h3. Тарифы и 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 Примечание - не забывайте, что в фаерволе имеет значение порядок следования правил. h2. NAT Если Вы раздаете юзерам серые адреса и у Вас на внешнем фейсе в Микротике один белый (реальный) адрес - не забудьте настроить маскарадинг. В самом простом случае: /ip firewall nat add action=masquerade chain=srcnat disabled=no out-interface=ether1-Ext где ''ether1-Ext'' замените на имя вашего внешнего интерфейса. Другие варианты настройки NAT выходят за рамки этой статьи. В Сети сущестует множество примеров. h2. Динамическая раздача IP адресов Для экономии белых адресов есть смысл раздавать их динамически и сохранять логи для спецслужб. Для динамической выдачи адресов существует соответствующая вкладка в настройке тарифа в Ideco Manager: "Динамический IP/NAT" Пул адресов привязывается к юзеру в его "карточке" (вкладка "Информация" в Ideco Manager). Если нужно выдавать адреса из пулов, привязанных к конкретным NASам, тогда пул привязывается в настройке каждого NAS в Ideco Manager: "Оборудование" \-> "Маршрутизаторы" \-> "открываете" нужный NAS и в соответствующем нисподающем списке "Динамические IP" - выбираете пул. Это может быть необходимо в специфической конфигурации маршрутизации - когда имеется несколько NASов и каждый "держит" свою белую подсеть, и клиенты могут рандомно подключаться к любым NASам (для балансировки и отказоустойчивости) - таким образом при подключении анализируется к какому NASу подключается юзер и исходя из этого выдается адрес из нужного пула (т.е. пул не привязан жестко к юзеру). Все вышесказанное - в контексте использования RADIUS протокола. h2. IPoE авторизация Есть тенденция избежать использование тунелей VPN (PPTP, L2TP, PPPoE) - чтобы упростить жизнь юзерам. Ведь VPN тунели изначально придумали совсем не для того, чтобы "подключаться к интернету". Это уже позже их к этому приспособили. Но на самом деле не существует никакой "авторизации 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 с RADIUS. !Cd26baaca499.png! Другими словами - когда клиент делает DHCP запрос - Микротиk будет "переспрашивать" в биллинге через RADIUS - можно ли юзеру выдать адрес, и если можно, то какой. Профита от этой схемы пока мало - из коробки Ideco на данный момент не готова для этой схемы - потому что нужно надфилем подпилить процедуры. В частности Микротик шлет пустое поле пароля - Ideco это не "нравится". Можно с помощью костылей "воткнуть" "общий" пароль, но зачем? ) И есть еще один нюанс - DHCP MikroTik не умеет Radius аккаунтинг. Т.е. объемы нужно в любом случае считать с помощью netflow (99,99999% так и делают). Но вот логика Ideco завязана на radius update пакеты - чтобы юзер оставался "онлайн" . Дальше пока даже не стал разбираться с нюансами: dhcp lease time, release (освобождение адреса), переподключения и прочие заморочки из реальной жизни. h3. DHCP Mikrotik + Opt.82 + Radius Тут справедливо все вышесказанное, с той лишь разницей, что Тик может еще и опц82 передавать в радиус запросе для биллинга. И в биллинге можно ее анализировать вместо MAC юзера. (MAC можно игнорить - нафег он нам нужен). Для этого нужно прописать адрес DHCP relay (если релеев много - значит указать "принимать со всех - 255.255.255.255 или 0.0.0.0 - точно не помню - попробуйте оба варианта). !B1b27531d95e.png! Недостатки схемы те же, что и в предыдущем случае. К тому же - в ideco нужно правильно "разбирать" поля опции82 - так как они для разных вендоров разные - тоже из коробки не будет работать пока-что. Если кому сильно надо - нужно обращаться к разработчкиам - '''они подпилят'''. (Конечно, если у Вас не бесплатная лицензия, поддержка на которую не оказывается). Хотя на демо версию - поддержка есть. И если Вы убедите их - что Вы - потенциальный клиент - собрались купить лицензию, и лишь "вот этот вот нюанс" вас останавливает ....))) h3. WiFi и HotSpot: Web авторизация + CHAP + Radius Данная схема абсолютно рабочая и кошерная. Позиционируется для настройки беспроводных точек доступа Микротик и беспроводных клиентов (аля смартфоны/нетбуки/планшеты - в гостиницах, общагах, библиотеках и прочих аэропортах. В данном случае от биллинга не потребуется абсолютно никаких особенных настроек - т.е. делаете все по инструкции выше. В том числе и скрипт обработки событий является универсальным. Расставляем точки доступа Микротик. Настраиваем их в биллинге как и "обычные" NAS Микротик. С той лишь разницей - на точках доступа используется не VPN, а HOTSPOT - в котором есть полноценный RADIUS c аккаунтингом: !6a3ed6a90ef2.png! Включаем Web авторизацию + CHAP: Dba8e01fd594.png\! В итоге в браузере клиента появится окошко, где нужно вводить имя и пароль. Эту страничку можно разукрасить как угодно. И добавить разных ссылок и полезных каментов и объясняшек и т.д. Также можно указать сайты, которые могут быть доступны без авторизации (Walled Garden). В Сети легко находятся примеры настройки MikroTik HotSpot и Wireless. Плюсы - юзерам со смартфонами не нужно (не возможно) возиться с тунелями - вместо этого есть понятное окошко веб-авторизации. Минусы - нету. (просто нужно понимать нишу - для которой эту схему нужно юзать) Кстати - HotSpot работает не только на беспроводном фейсе, но и вполне себе на Ethernet интерфейсах. О чем ниже... h4. WiFi и Ethernet HotSpot: MAC+Radius Можно использовать авторизацию по MAC адресу. \!\!\! При этом, напоминаю, HotSpot не только для беспроводной сети - он отлично работает и на ethernet интерфейсах. И если веб авторизация явно предназначена для беcпроводных клиентов в лице разных мобилок и прочих девайсов аля планшетики, то хотспот + MAC авторизация - вполне органично может использоваться в Ethernet сети для проводных клиентов. !7a66ac754671.png! На ideco соответственно вместо имени и chap пароля юзера - проверяется только MAC адрес юзера и общий пароль. (на скрине выше заполните поле MAC Auth. Password ), и пропишите этот "общий" радиус пароль в Ideco Manager - в св-вах соответсвующего NASa ("оборудование" - "маршрутизаторы" - ... выбираем NAS ... - "USERS_PSW" ): !cc975314fe76.png! передается заглавными символами. По-поводу дефисов и двоеточий - выбирайте шаблон в Тике в ниспадающем списке "MAC Format" ("IP - Hotspot - Radius"): !f22db194be50.png! \!\!\! Внимание - вписывайте MAC в поле "Логин" - в карточке юзера в Ideco менеджере. !bcea2859e234.png! \!\!\! Нужно отключить фишку на Ideco, которая режет пробелы и заглавные символы в радиус запросах (да - таки эта фишка кроме пробелов еще режет символы A-Z - чуть ниже расскажу зачем вообще она нужна): !B6b501aba4cf.png! (кстати - никто не мешает редактировать и тюнить на Ideco - конфиг freeradius сервера - если понимаете что и для чего...) Внезапно в подсказке написано, что эту фишку "Не используйте, если отключаете сессии по логину". Тащем-та наоборот ))))))))))) - используйте эту фишку в схеме с VPN - если киляете по имени (а мы именно по имени киляем наши VPN тунели - а то если юзера пускать с любым регистром, то имя в базе и по факту не совпадут - и юзер не кильнется и будет висеть вечно ). (по IP килять не очень надежно в схеме с динамической раздачей адресов). Отключайте эту фишку - если киляете не по имени (а по адресу и id радиус сессии - но тогда отредактируйте соответственно скрипт обработки событий), или не юзаете VPN или Web авторизацию. В ideco манагере - в общих настройках - параметр "Регистрозависимый логин" вообще никогда не включайте - на данный момент оно работает так: Приходит запрос радиус с NAS - мол - вот вам имя и пароль - есть ли такой юзер? Разрешен ли ему вход и какой адрес и прочие параметры ему выдать? Если регистр не совпадает - сервер должен бы ответить отказом - т.е. нельзя этому юзеру входить. Но Ideco просто не выдает IP адрес - "сервер не назначил адрес". Тогда юзер сам себе назначает адрес (да, прямо в настройках впн) и спокойно подключается. Страху, конечно, никакого - но юзеры часто любят прописать себе на виртуальный фейс - адрес самого впн сервера или еще какого-нить девайса вашей сети или соседа - и тогда происходят весьма интересные вещи.... Попробуйте сами ))))) Итоги: Схема - рабочая. Если не смущает собирать мак адреса клиентов и есть возможность обеспечить защиту от подмены мак адресов. Условно позиционируем эту схему для небольшой сети. h4. VirtualAP Например: в торговом центре есть ваши точки доступа. 90% юзеров юзают говносмартфоны и говнопланшеты. Но есть 10% - которым нужно подключить какие-то банковские терминалы и прочие вундервафли, которые не умеют ни впн, ни веб авторизацию и вообще вай фай не умеют ))) Ставим им тоже вайфай роутер (например - клиентский микротик RB751 - в нем таки уже есть внешняя и внутренняя антены - настраиваем там прием по внешней, раздачу - с внутренней - на другой частоте. Авторизацию на нем - внимание - VPN \!\!\! (это мы уже умеем). Роутер раздает внутри помещения (мощность можно поубавить) опять же на говносматрфоны клиента по ключу (их личная частная сеть). А вундервафлю клиента (банковский терминал и прочие стационарные штуки) вообще включаем проводами к юзерскому роутеру, который уже "авторизован" и раздает невозбранно Инет всем подключенным по - внезапно IPoE ). Для того, чтобы наша (провайдерская) точка доступа могла и хотспот и впн одновременно - придумали Virtual AP - создаем на физическом беспроводном фейсе сколько нужно виртуальных AP - каждая из которых может иметь свой SSID, и типы авторизации (на одной AP включаем hotspot, на другой не включаем и юзаем VPN как обычно), а также наличие/отсутствие своих ключей. Для веб авторизации - оставить видимую беспроводную сетку без ключа. Для остальных извратов - сетку скрыть - ключом закрыть и настраивать индивидуальные роутеры клиентов - чтобы остальных не путать. h3. IPoE без Radius ''Особенности и причины использования IPoE без RADIUS AAA.'' Подведем промежуточные итоги: Если юзать DHCP на Тике без радиус - биллинг вообще ничего не знает о адресах юзера. Схема не кошерная. Если юзать DHCP на Тике + радиус - биллинг выдает адреса и все почти хорошо, кроме тог, что схема не допилена ). (Знаю людей, которые юзают эту схему с самописным биллингом (они то и пропихнули тему - чтобы тиковцы запилили поддержку DHCP + Opt82 + radius )) Если юзать хотспот - то все кошерно, но больше подходит для беспроводных клиентов. Поэтому рассмотрим следующие варианты: h4. DHCP Ideco + Opt.82 Итак, Микротик dhcp + radius + Ideco = пока не взлетел. Значит нужно юзать DHCP на биллинге - чтобы он таки был в курсе выданных адресов клиентам. Настройки DHCP Ideco описаны в оффициальной документации. \!\!\! Скрипт обработки событий универсальный - не требует допила - \!\!\! можно юзать '''смешанную схему''' - и VPN и ip авторизацию. Соответственно и настройки NASа в Ideco - ничем не отличаются: !61eea54a757d.png! (пусть вас не смущают галочки "лишние" - это для универсальности: VPN + radius и схема IPoE без радиус могут работать одновременно\!). Понятно, что радиус и впн можно и не настраивать - IPoE все равно будет работать\! Особенности: В этой схеме - юзеру выставляется тип "авторизации по IP". Так как приходится обходится без радиуса - то биллинг ни черта не в курсе через какой NAS там форвардится юзерский траф - поэтому в "карточке" клиента нужно прописать NAS IP и залочить галочку. !36223c24f223.png! Недостаток схемы - из-за отсутствия радиуса - нет фактического логина/логаута - нет постоянной "актуализации" в каком листе юзер должен находится. Событие "логин" происходит формально один раз. Юзер как бы подключен всегда - нет явных сессий по факту. Трафик рулиться с помощью редких событий - баланс негатив и позитив (так как юзеры платят сразу на неделю или даже месяц). В итоге может происходит "рассинхрон" между биллингом и NAS. Пару примеров - почему это может произойти: - Юзер оплатил деньги. Произошло событие "баланс позитив". В этот момент NAS был в ребуте или связь временно между серверами отсутсвовала (достаточно одну команду всего потерять). И далее юзер может хоть сто раз перезагружаться - он остается в адрес лист негатив. Так же верна и обратная ситуация - денежки кончились у юзера - не прошло событие баланс негатив по любой из причин - и потом ваш юзер может юзать Инет без денег хоть полгода - пока биллинг не перезагрузишь. * NAS пришлось менять на новый - придется актуализировать вручную адрес-листы. * Понадобилось восстановить конфиг NASа из бэкапа - также придётся актуализировать вручную адрес-листы. и т.д. Понятно - что в жизни потеря команд будет не часто происходить. Но все же периодически рекомендуется делать сверку "вручную" между биллингом и NASом. Достоинства схемы - простая до безобразия. Итог - схема без радиуса - это не совсем надежная четкая схема. При небольшом к-ве юзеров можно визуально вручную делать сверку, но при тысячах юзеров - нереально ). Рекомендуется для относительно небольшой сети. Внезапно можно написать скрипт или программку синхронизации биллинга и NAS и запускать в планировщике по расписанию с заданным интервалом. Тогда можно и для относительно большой сети эту схему применить. h4. DHCP Ideco + MAC Тоже самое, что и предыдущая схема, только вместо опции82 - юзается MAC - для раздачи адресов. h4. IPoE без DHCP и Radius Можно в карточке юзера: \-прописать его адрес вручную \-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] |