Информация предоставлена 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 и MikroTik Router OS 5.22
|
|
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]\]
|
!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 сессии если надо и т.д.
При этом Биллинг стоит в сторонке и выполняет следующие функции: учет абонентов в базе данных, авторизация, ведение счетов, тарификация согласно тарифным планам, генерация событий, прием платежей, отчеты, интерфейс для администраторов, кассиров и прочих сотрудников компании. Личный кабинет для пользователей и прочее.
|
Далее рассмотрим подробней различные аспекты совместной работы двух систем.
|
== Базовая Настройка Ideco АСР ==
|
h2. Базовая Настройка Ideco АСР
|
Инструкция актуальна для версии Ideco АСР 3.9.7
|
...
На более старых версиях существуют мелкие и боле серьезные отличия, но я не буду их рассматривать.
|
Просто замечу: я рекомендую использовать для коммерческого использования именно версию 3.9, так как продукт за последний год сильно доработан и улучшен.
|
=== Создание пользователя root ===
|
h3. Создание пользователя root
|
Первым делом создайте пользователя ''root''
|
... (по умолчанию суперпользователь отключён).
В официальной документации раздел называется ''Включение постоянного удаленного помощника"''
|
(не путать с устаревшим разделом: "Создание пользователя root").
|
=== Консольное меню ===
|
h3. Консольное меню
|
Откройте консольное menu
|
!Файл:0f4d8356d57d.png!
|
|
\[[Файл:0f4d8356d57d.png]\]
|
h4. RADIUS
|
|
==== RADIUS ====
|
Настройте \[[RADIUS]\] сервер таким образом:
|
...
|
''Конфигурирование сервера \-> RADIUS-Сервер...''
|
[x] Включить RADIUS-сервер
|
[x] Удалять лишние пробелы из логина RADIUS
.
|
... .
.
|
[x] Использовать процедуры версии 6
|
==== \[[NetFlow]\] ====
|
h4. NetFlow
|
|
h3.
|
''Конфигурирование сервера \-> NetFlow коллектор...''
|
... UDP-порт для приема 9996
|
[x] Приём NetFlow потоков с разных источников
|
==== SSH managment ====
|
h4. SSH managment
|
|
h3.
|
для удаленного входа в консоль биллинга используется протокол \[[SSH]\]
|
... ''Конфигурирование сервера \-> Безопасность...''
Поставьте отметку в следующих пунктах:
[x] Разрешить управление файлами по SSH
[x] Разрешить полное удаленное управление по SSH
|
и пропишите свой ''IP-адрес компьютера администратора'':
|
[http://s008.radikal.ru/i306/1210/c0/0cf1dda0db01.png]
|
!0cf1dda0db01.png!
|
Для возможности правки некоторых файлов нужно в локальном меню зайти в пункт ''Сервис'' и нажать на пункт ''"Разрешить запись из \[[SFTP|WinSCP]\] на раздел с резервными копиями"''.
|
[http://s13.radikal.ru/i186/1210/ed/e3bd87c5c3c1.png]
|
!e3bd87c5c3c1.png!
|
|
==== События и скрипты ====
В локальном меню проверьте наличие галочки в пункте:
|
h4. События и скрипты
|
|
В локальном меню проверьте наличие галочки в пункте:
|
''Конфигурирование сервера \-> Дополнительные настройки \-> Настройки для разработчиков...''
[x] Запускать скрипт обработки событий
|
[http://s019.radikal.ru/i604/1210/68/3e513a6fffa1.png]
|
!3e513a6fffa1.png!
|
Перезагрузите сервер Ideco корректно из меню:
|
[http://s017.radikal.ru/i417/1210/90/699cbf874a8a.png]
|
!699cbf874a8a.png!
|
"Зайдите" на сервер с помощью \[[SFTP]\] на порт 33 под учетной записью root.
|
...
(если вы админите из-под венды :-) \- то один из популярных клиентов - это WinSCP)
|
Я в линухе "из коробки" ввожу прямо так:
|
\[[Файл:E394e1c7e08e.png]\]
|
!E394e1c7e08e.png!
|
Перейдите в директорию <tt>/var/lib/event/</tt>
|
...
Откройте на редактирование файл <tt>event_inc.sh</tt>
|
Выделите все и удалите. Затем вставьте следующее:
{code}
|
/usr/bin/selfkiller -30:TERM -50:KILL & disown -a
|
LOG_LEVEL=ALL
|
sendsms(){
sms="${sms//[^0-9]/}"
if [ "${#sms}" -lt 11 ]; then
LOG WARN "Phone number of abonent $id is too short. SMS not sent."
return 1
fi
|
|
}
|
SENDER=$1; shift
EVENT=$1; shift
|
... DATA=$@
for VAR in $DATA; do
[[ "$VAR" = *"="* ]] && eval ${VAR%%=*}=\'${VAR#*=}\'
done
LOG INFO "$SENDER $EVENT $DATA"
##################################################################################################
telnet_user="user2"
telnet_password="YOUR_TELNET_PASSWD"
RADIUS_SECRET="YOUR_RADIUS_SECRET"
case "$nas_ip" in
"192.168.10.9")
nas_identity="nas1"
;;
"192.168.10.10")
nas_identity="nas2"
;;
"192.168.10.11")
nas_identity="nas3"
;;
esac
##################################################################################################
case "$EVENT" in
|
##################################################################################################
"balance_negative")
|
if [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then
|
/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
|
... ;;
|
##################################################################################################
"balance_positive")
|
if [ "$radius_logged" = "1" -a "$nas_ip" != "0.0.0.0" ]; then
|
/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
fi
|
... ;;
##################################################################################################
"rad_acc_start")
if [ "$nas_ip" != "0.0.0.0" ]; then
if [ "$over_limit" = "0" ]; then
/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
else
/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
fi
;;
##################################################################################################
"rate_set")
if [ "$logged" = "1" -a "$nas_ip" != "0.0.0.0" -a "$over_limit" = "0" ] ; then
/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
fi
;;
##################################################################################################
user_data_changed|user_data_changed_before)
if [ "$nas_ip" != "0.0.0.0" ]; then
echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"radius_update_err")
if [ "$nas_ip" != "0.0.0.0" ]; then
echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
user_disconnect|get_info_fail|rad_acc_timeout)
if [ "$nas_ip" != "0.0.0.0" ]; then
echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"rad_acc_stop")
if [ "$nas_ip" != "0.0.0.0" ]; then
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
##################################################################################################
"try_double_login")
if [ "$nas_ip" != "0.0.0.0" ]; then
echo "User-Name=$login, NAS-IP-Address=$nas_ip" | radclient -r 1 $nas_ip:3799 disconnect $RADIUS_SECRET
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
;;
|
##################################################################################################
"login") #Only for IP_auth
|
if [ "$nas_ip" != "0.0.0.0" -a "$auth_type" = 1 ]; then
|
if [ "$over_limit" = "0" ]; then
/usr/local/bin/expect /var/lib/event/event3.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity $ceil_in $ceil_out
|
... else
/usr/local/bin/expect /var/lib/event/event1.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
fi
;;
|
##################################################################################################
"logout") #Only for IP_auth
|
if [ "$nas_ip" != "0.0.0.0" -a "$auth_type" = 1 ]; then
|
/usr/local/bin/expect /var/lib/event/event2.sh $nas_ip $ip $telnet_user $telnet_password $nas_identity
fi
|
... ;;
##################################################################################################
*)
:
;;
|
esac
{code}
|
{{caution\|text=
|
'''Важно\!\!\!''' Если в венде это делаете - Файл должен содержать 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 права.
|
=== Manager ===
|
h3. Manager
|
Интерфейс управления Ideco Manager написан и скомпилирован под венду, но в wine работает без вопросов.
|
==== Общие настройки ====
|
h4. Общие настройки
|
|
h3.
|
''Сервис \-> Настройки''
|
\[[Файл:E5be392f8822.png]\]
|
!E5be392f8822.png!
|
Таймаут accounting update - данную переменную можете ставить сутки (в секундах, ессно).
|
==== Оборудование ====
|
h4. Оборудование
|
|
h3.
|
Добавим параметры нашего NASа по примеру:
|
\[[Файл:61eea54a757d.png]\]
|
!61eea54a757d.png!
|
|
==== Пулы ====
|
h4. Пулы
h3.
|
Добавляете пул адресов, которые через RADIUS будут выдаваться юзерам в VPN тунели
(не имеет значения - белые адреса, либо серые).
Позже также мы рассмотрим варианты с "динамическими" и "статическими" адресами, а также нюансы с белыми и серыми адресами, и варианты без VPN тунелей и использование DHCP.
|
!2ec78ce4ddc5.png!
|
|
\[[Файл:2ec78ce4ddc5.png]\]
|
h2. Базовая настройка MikroTik ROS
|
|
== Базовая настройка MikroTik ROS ==
|
h3. Identity
|
|
=== Identity ===
|
Как уже упоминалось ранее - имя вашего сервера Микротик нельзя менять от балды, по дефолту пропишите
в разделе ''System \-> Identity'' : ''nas1''
|
\[[Файл:5b0b2b6aa11b.png]\]
|
5b0b2b6aa11b.png\!
|
|
=== Clock ===
|
h3. Clock
|
Нужно настроить время на NASе для нормальной работы и логов.
Пропишите ближайшие к Вам два надежных сервера NTP.
|
!5b2cb3dfe4a1.png!
|
|
\[[Файл:5b2cb3dfe4a1.png]\]
|
h3. Telnet group/user
|
|
=== Telnet group/user ===
|
В биллинге автоматически выполняются скрипты по различным событиям и производят определенные манипуляции на сервере NAS через telnet.
|
... Ка уже выше писалось - я просил записать на бумажку имя телнет юзера user2 и придуманный вами пароль, который вы ранее прописали в скриптах обработки событий.
Пришло время настроить специальную группу и этого юзера на Микротике:
Открывайте в winbox меню: ''System \-> Users''
и там щелкаете по вкладке ''Groups''
Затем на плюс (добавить новую группу).
Придумайте имя группы (например telnet)
Расставьте галочки напротив следующих прав:
- write
- test
- telnet
- read
|
нажмите Ok.
|
\[[Файл:D3b988179489.png]\]
|
!D3b988179489.png!
|
Далее жмите вкладку ''Users''.
|
...
Добавляйте нового юзера с именем user2 и выбирите из нисподающего списка имя вышесозданной группы.
Обязательно укажите, что доступ этому юзеру разрешен только с IP адреса биллинга - в поле Allowed Address: укажите IP адрес вашего билинга.
|
Укажите и подтвердите пароль созданного юзера ''user2'' (тот, что я просил выше придумать вместо YOUR_TELNET_PASSWD и записать на бумажке)
|
\[[Файл:6995efa7efae.png]\]
|
!Файл:6995efa7efae.png!
|
|
=== DNS ===
|
h3. DNS
|
Для корректной работы интернет сервисов необходимо настроить службу \[[DNS]\].
|
...
Схема такая - на Микротике включаем кеширующий днс. Указываем ему несколько надежных днс служб - обычно используются серверы вышестоящего провайдера (Не рекомендую более двух серверов указывать). И нашим юзерам, например с помощью опции DHCP - передаем в качестве днс сервера - локальный адрес NAS сервера. Таким образом юзер делает днс запросы на Микротик сервер, если у него в кеше нету такой записи, то микротик делает запрос в прописанные "вышестоящие" днс серверы, и затем возвращает ответ нашим юзерам. Все это происходит обычно быстрее, чем вы читаете этот абзац )))))
|
|
\[[Файл:E8139d99b8af.png]\]
|
!Файл:E8139d99b8af.png!
|
|
=== DHCP ===
|
h3. DHCP
|
Если Вы используете DHCP на NASе, то отключите его в биллинге.
|
...
|
Запустите мастера настройки DHCP сервера на Микротике.
|
\[[Файл:F6a4a1263577.png]\]
|
!F6a4a1263577.png!
|
Подробно пока не буду заострять внимания на этих банальных настройках - в Сети множество примеров.
|
...
Лишь некоторые очевидные нюансики:
Юзеры должны находится в одном сегменте с сервером \[[DHCP]\] (один \[[VLAN]\], один широковещательный домен) - иначе нужно использовать DHCP Relay (обычно включают эту фишку на "умном" коммутаторе).
При настройке DHCP сервера - одна из опций, которая юзерам передается кроме IP адреса - это адрес \[[DNS]\] сервера - проверьте, чтобы этот адрес был адресом локального фейса Микротика.
|
Если вы решили использовать авторизацию PPPoE для юзеров - то выдавать IP адреса на физический интерфейс юзеров - не обязательно - тунель работает на основе MAC адресов клиента и сервера (на втором уровне (L2) семиуровневой модели \[[OSI]\]). (Но если все таки юзерам нужно видет друг друга в локалке мимо тунеля и сервера - тогда, конечно, назначайте адреса на физические фейсы юзерских девайсов).
|
=== VPN (secret/profile/radius) ===
|
h3. VPN (secret/profile/radius)
|
Самый лучший из тунелей - это \[[PPPoE]\] - так как он кушает гораздо меньше ресурсов, чем PPTP - потому что в микротике реализован как модуль ядра ("ядерный"), в отличие от PPTP/L2TP - демоны которых крутяться в userspace - пространстве для юзеров и из-за частой смены контекста выполняются "лишние" операции.
|
...
С PPPoE есть нюанс - клиент и сервер должны быть в одном сегменте Ethernet, в противном случае нужно использовать PPPoE agent на управляемых свичах, чтобы релеить пакеты из одного сегмента в другой. Любо юзать вместо PPPoE - PPTP (не рекомендую) либо \[[L2TP]\] тунели. Ну, а вообще можно хоть одновременно все три типа тунелей юзать - но кому такой зоопарк нужен? А еще лучше не юзать тунели вообще (так называемый IPoE), но об этом потом....
|
Итак - если вы решили юзать PPPоE - отключите PPPoE сервер в биллинге:
|
\[[Файл:1484afa87036.png]\]
|
!Файл:1484afa87036.png!
|
Далее настройте профиль default:
|
\[[Файл:798feb700475.png]\]
|
!798feb700475.png!
|
и
|
\[[Файл:De78a5f63cfd.png]\]
|
!De78a5f63cfd.png!
|
|
... Затем включите радиус аутентификацию и аккаунтинг, и создайте ppp секрет, при этом выбирите из нисподающего списка нужный Вам Service:
|
|
\[[Файл:Ebfff5a9b21d.png]\]
|
!Ebfff5a9b21d.png!
|
Включаем PPPoE сервис на локальном интерфейсе с профилем default:
|
\[[Файл:08274ccdb2f6.png]\]
|
!08274ccdb2f6.png!
|
Если вместо PPPoE решили юзать PPTP или L2TP - включите нужный Вам сервис:
|
\[[Файл:84cef8874df8.png]\]
|
!84cef8874df8.png!
|
|
=== Traffic Flow ===
|
h3. Traffic Flow
|
Для подсчета объемов трафика и сбора подробной статистики нужно отсылать биллингу инфу о проходящем сквозь NAS трафике юзеров:
|
\[[Файл:0356d6ff15f4.png]\]
|
!0356d6ff15f4.png!
|
Включите traffic flow, выбирите все интерфейсы (all) и укажите куда отсылать netflow v5 - адрес вашего биллинга.
|
=== Radius Accounting ===
|
h3. Radius Accounting
|
Я лично отсылаю netflow версии 9 не на биллинг, а на отдельный сервер. (для справки - я юзаю debian + nfdump + nfsen). А объемы трафика у меня в биллинге считаются не с помощью netflow, а с помощью Radius протокола.
|
!F118f4e0c220.png!
|
|
\[[Файл:F118f4e0c220.png]\]
|
Это нужно, когда у вас десятки тысяч юзеров и гигабиты трафика в секунду - чтобы не напрягать биллинг. Таким образом легко можно масштабировать \[[NetFlow]\] коллекторы - например условно на каждых 5 NASов - свой нетфлоу коллектор.
|
... Минус такого метода один - с помощью радиуса мы можем считать только объемы, но биллинг ничего не будет знать об посещаемых IP адресах, а значит не сможем сделать в помегабайтных тарифах - льготные или бесплатные ресурсы. Но в век безлимитов этот нюанс имеет все меньше и меньше значения. Сейчас "льготность" может заключаться в бОльших скоростях на льготные ресурсы - о чем мы поговорим позже.
Еще одно замечание - по умолчанию NAS скидывает промежуточную информацию (Radius Accounting) на биллинг каждые 300 сек. Если юзеров очень много (тысячи их) - есть смысл это время увеличить. Для этого нужно в биллинге в манагере в настройках каждого тарифа - > во вкладке RADIUS - добавить такой атрибут:
Acct-Interim-Interval := 2400
|
(важно - в общих настройках в манагере '' радиус аккаунтинг таймаут'' должен быть больше чем Acct-Interim-Interval, и как я уже выше советовал - ставьте таймаут сутки)
|
=== RADIUS ===
|
h3. RADIUS
|
Включаем radius пока только для VPN (ppp), позже рассмотрим работу radius + DHCP и + Hotspot
|
\[[Файл:Eae38e5b953f.png]\]
|
!Eae38e5b953f.png!
|
Прописываем адрес биллинга. И указываем ваш радиус секрет (тот, который вы придумали YOUR_RADIUS_SECRET)
|
== Тарифы. Ideco ==
|
h2. Тарифы. Ideco
|
Рассмотрим четыре базовых тарифа и "турбокнопку".
|
...
Пронумеруем для удобства эти сущности.
|
Прежде чем создать тарифы - создайте в Ideco Manager "правила и сети". А лучше воспользуйтесь заготовками, которые есть в базе данных для примера. И не забывайте про онлайн документацию.
|
=== Простой безлимит (№1) ===
|
h3. Простой безлимит (№1)
|
|
\[[Файл:Dd19953e602e.png]\]
|
!Dd19953e602e.png!
|
Пусть вас не смущает, что я написал скорость "1". Это не килобиты в данном случае, а номер, который будет передаваться в Микротик. Есть лицензия на Ideco - которая позволяет обойтись без использования NAS и пропускать трафик через сервер биллинга - в этом случае тут пишутся реальные скорости в килобитах для шейпера Ideco SoftRouter. В нашем случае трафик идет не через Ideco, а через Микротик - там мы и будем позже настраивать шейпер.
|
...
Не забудьте поставить галочку "блокировать при превышении лимита".
Не забудьте указать абонентскую плату.
|
{{note\|text=В описываемой мной схеме - RADIUS атрибуты в тарифе прописывать не нужно\!\!\!}}
|
\[[Файл:7a88f3b62132.png]\]
|
!7a88f3b62132.png!
|
|
=== h3. Условный безлимит (скорость зависит от объема)(№2) ===
|
|
\[[Файл:Ed8c10cee402.png]\]
|
!Ed8c10cee402.png!
|
До 200 Гигов входящего объема - скорость номер 2
|
\[[Файл:A85365aa5229.png]\]
|
!A85365aa5229.png!
|
После 200 Гигов входящего объема - скорость номер 22 - до конца месяца.
|
\[[Файл:35f51c301cb9.png]\]
|
!35f51c301cb9.png!
|
|
=== h3. "Помегабайтный" (цена зависит от объема) (№3) ===
|
|
\[[Файл:Ed0a1a7fc802.png]\]
|
!Ed0a1a7fc802.png!
|
Тут никто не мешает добавить других правил и подсетей с другой стоимостью мегабайтов.
И никто не мешает указать разную стоимость трафика для разных объемов, времени суток, и для входящего и исходящего - раздельно.
|
=== h3. Безлимит - разная скорость в разное время суток (№4) ===
|
|
\[[Файл:D1fbdc2856dc.png]\]
|
!D1fbdc2856dc.png!
|
{{note\|text=Внимание\! Мы будем менять скорость в разное время суток для этого тарифа - на Микротике (об этом позже).
Поэтому тут в Ideco не нужно указывать время и скорость.}}
|
=== Турбокнопка (№5) ===
|
h3. Турбокнопка (№5)
|
|
\[[Файл:4657a9a9e7e0.png]\]
|
!4657a9a9e7e0.png!
|
Укажите стоимость услуги, номер скорости, время действия турбо-режима, и разрешите заказ через веб кабинет.
|
...
|
Важно: Во всех тарифах отключите "Разрешить все услуги с флагом "заказ через Web" и явно добавьте в каждый тариф нужные услуги, в том числе и турбокнопки, коих можно создать неограниченное к-во с разными параметрами цены. скорости и времени действия.
|
\[[Файл:37d92db5de90.png]\]
|
!37d92db5de90.png!
|
|
=== Настройка группы и "карточки" юзера ===
|
h3. Настройка группы и "карточки" юзера
|
Создайте группу по примеру:
|
\[[Файл:277309f71e9a.png]\]
|
!277309f71e9a.png!
|
Cоздайте юзеров по примеру:
|
\[[Файл:4f19a5fd80fa.png]\]
|
!4f19a5fd80fa.png!
|
''Комментарии:''
|
...
Не используйте заглавные буквы, кирилицу, пробелы в логинах юзеров\!\!\!
Уберите галочку isNAT - даже если Вам нужен NAT - мы его настроим позже на Микротике.
|
Внимательно с признаком "финансовый" и "порогом отключения" и "периодом формирования акта" (варианты использования - в официальной документации)
|
== Тарифы. MikroTik ==
|
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
|
=== Маркировка трафика в Mangle ===
|
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]\]
|
!744d9be53f95.png!
|
|
=== Cоздание типов очередей PCQ ===
|
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]\]
|
!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]\]
|
!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]\]
|
!5d7869d4edbb.png!
|
|
=== Тарифы и Firewall Filter ===
Итак закончили с разметкой трафика и шейпингом - теперь приступим к фильтрации трафика:
|
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
|
Примечание - не забывайте, что в фаерволе имеет значение порядок следования правил.
|
== NAT ==
Если Вы раздаете юзерам серые адреса и у Вас на внешнем фейсе в Микротике один белый (реальный) адрес - не забудьте настроить маскарадинг. В самом простом случае:
|
h2. NAT
|
|
Если Вы раздаете юзерам серые адреса и у Вас на внешнем фейсе в Микротике один белый (реальный) адрес - не забудьте настроить маскарадинг. В самом простом случае:
|
/ip firewall nat
add action=masquerade chain=srcnat disabled=no out-interface=ether1-Ext
|
...
где ''ether1-Ext'' замените на имя вашего внешнего интерфейса.
Другие варианты настройки NAT выходят за рамки этой статьи. В Сети сущестует множество примеров.
|
|
== Динамическая раздача IP адресов==
Для экономии белых адресов есть смысл раздавать их динамически и сохранять логи для спецслужб.
|
h2. Динамическая раздача IP адресов
|
|
Для экономии белых адресов есть смысл раздавать их динамически и сохранять логи для спецслужб.
|
Для динамической выдачи адресов существует соответствующая вкладка в настройке тарифа в Ideco Manager:
|
... "Динамический IP/NAT"
Пул адресов привязывается к юзеру в его "карточке" (вкладка "Информация" в Ideco Manager).
Если нужно выдавать адреса из пулов, привязанных к конкретным NASам, тогда пул привязывается в настройке каждого NAS в Ideco Manager:
"Оборудование" \-> "Маршрутизаторы" \-> "открываете" нужный NAS и в соответствующем нисподающем списке "Динамические IP" - выбираете пул.
Это может быть необходимо в специфической конфигурации маршрутизации - когда имеется несколько NASов и каждый "держит" свою белую подсеть, и клиенты могут рандомно подключаться к любым NASам (для балансировки и отказоустойчивости) - таким образом при подключении анализируется к какому NASу подключается юзер и исходя из этого выдается адрес из нужного пула (т.е. пул не привязан жестко к юзеру).
|
Все вышесказанное - в контексте использования RADIUS протокола.
|
== IPoE авторизация==
|
h2. 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 ====
|
h3. IPoE с Radius
|
|
h4. DHCP Mikrotik + MAC + Radius
|
В Микротике есть возможность связать DHCP с RADIUS.
|
\[[Файл:Cd26baaca499.png]\]
|
!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]\]
|
!B1b27531d95e.png!
|
Недостатки схемы те же, что и в предыдущем случае. К тому же - в ideco нужно правильно "разбирать" поля опции82 - так как они для разных вендоров разные - тоже из коробки не будет работать пока-что. Если кому сильно надо - нужно обращаться к разработчкиам - '''они подпилят'''. (Конечно, если у Вас не бесплатная лицензия, поддержка на которую не оказывается). Хотя на демо версию - поддержка есть. И если Вы убедите их - что Вы - потенциальный клиент - собрались купить лицензию, и лишь "вот этот вот нюанс" вас останавливает ....)))
|
==== h3. WiFi и HotSpot: Web авторизация + CHAP + Radius ====
|
Данная схема абсолютно рабочая и кошерная.
|
...
Позиционируется для настройки беспроводных точек доступа Микротик и беспроводных клиентов (аля смартфоны/нетбуки/планшеты - в гостиницах, общагах, библиотеках и прочих аэропортах.
В данном случае от биллинга не потребуется абсолютно никаких особенных настроек - т.е. делаете все по инструкции выше. В том числе и скрипт обработки событий является универсальным.
Расставляем точки доступа Микротик. Настраиваем их в биллинге как и "обычные" NAS Микротик.
|
С той лишь разницей - на точках доступа используется не VPN, а HOTSPOT - в котором есть полноценный RADIUS c аккаунтингом:
|
\[[Файл:6a3ed6a90ef2.png]\]
|
!6a3ed6a90ef2.png!
|
Включаем Web авторизацию + CHAP:
|
\[[Файл:Dba8e01fd594.png]\]
|
Dba8e01fd594.png\!
|
В итоге в браузере клиента появится окошко, где нужно вводить имя и пароль. Эту страничку можно разукрасить как угодно. И добавить разных ссылок и полезных каментов и объясняшек и т.д.
|
...
Также можно указать сайты, которые могут быть доступны без авторизации (Walled Garden).
В Сети легко находятся примеры настройки MikroTik HotSpot и Wireless.
Плюсы - юзерам со смартфонами не нужно (не возможно) возиться с тунелями - вместо этого есть понятное окошко веб-авторизации.
Минусы - нету. (просто нужно понимать нишу - для которой эту схему нужно юзать)
|
Кстати - HotSpot работает не только на беспроводном фейсе, но и вполне себе на Ethernet интерфейсах. О чем ниже...
|
==== WiFi и Ethernet HotSpot: MAC+Radius ====
|
h4. WiFi и Ethernet HotSpot: MAC+Radius
|
|
|
Можно использовать авторизацию по MAC адресу.
\!\!\! При этом, напоминаю, HotSpot не только для беспроводной сети - он отлично работает и на ethernet интерфейсах. И если веб авторизация явно предназначена для беcпроводных клиентов в лице разных мобилок и прочих девайсов аля планшетики, то хотспот + MAC авторизация - вполне органично может использоваться в Ethernet сети для проводных клиентов.
|
[http://i047.radikal.ru/1210/3a/7a66ac754671.png]
|
!7a66ac754671.png!
|
На ideco соответственно вместо имени и chap пароля юзера - проверяется только MAC адрес юзера и общий пароль. (на скрине выше заполните поле MAC Auth. Password ), и пропишите этот "общий" радиус пароль в Ideco Manager - в св-вах соответсвующего NASa ("оборудование" - "маршрутизаторы" - ... выбираем NAS ... - "USERS_PSW" ):
|
[http://s017.radikal.ru/i414/1210/66/cc975314fe76.png]
|
!cc975314fe76.png!
|
|
MAC передается заглавными символами. По-поводу дефисов и двоеточий - выбирайте шаблон в Тике в ниспадающем списке "MAC Format" ("IP - Hotspot - Radius"):
|
|
[http://s019.radikal.ru/i639/1210/fa/f22db194be50.png]
|
!f22db194be50.png!
|
\!\!\! Внимание - вписывайте MAC в поле "Логин" - в карточке юзера в Ideco менеджере.
|
[http://s006.radikal.ru/i213/1210/7a/bcea2859e234.png]
|
!bcea2859e234.png!
|
\!\!\! Нужно отключить фишку на Ideco, которая режет пробелы и заглавные символы в радиус запросах (да - таки эта фишка кроме пробелов еще режет символы A-Z - чуть ниже расскажу зачем вообще она нужна):
|
\[[Файл:B6b501aba4cf.png]\]
|
!B6b501aba4cf.png!
|
(кстати - никто не мешает редактировать и тюнить на Ideco - конфиг freeradius сервера - если понимаете что и для чего...)
|
...
Внезапно в подсказке написано, что эту фишку "Не используйте, если отключаете сессии по логину".
Тащем-та наоборот ))))))))))) - используйте эту фишку в схеме с VPN - если киляете по имени (а мы именно по имени киляем наши VPN тунели - а то если юзера пускать с любым регистром, то имя в базе и по факту не совпадут - и юзер не кильнется и будет висеть вечно ). (по IP килять не очень надежно в схеме с динамической раздачей адресов).
Отключайте эту фишку - если киляете не по имени (а по адресу и id радиус сессии - но тогда отредактируйте соответственно скрипт обработки событий), или не юзаете VPN или Web авторизацию.
В ideco манагере - в общих настройках - параметр "Регистрозависимый логин" вообще никогда не включайте - на данный момент оно работает так:
Приходит запрос радиус с NAS - мол - вот вам имя и пароль - есть ли такой юзер? Разрешен ли ему вход и какой адрес и прочие параметры ему выдать? Если регистр не совпадает - сервер должен бы ответить отказом - т.е. нельзя этому юзеру входить. Но Ideco просто не выдает IP адрес - "сервер не назначил адрес". Тогда юзер сам себе назначает адрес (да, прямо в настройках впн) и спокойно подключается. Страху, конечно, никакого - но юзеры часто любят прописать себе на виртуальный фейс - адрес самого впн сервера или еще какого-нить девайса вашей сети или соседа - и тогда происходят весьма интересные вещи.... Попробуйте сами )))))
Итоги:
|
Схема - рабочая. Если не смущает собирать мак адреса клиентов и есть возможность обеспечить защиту от подмены мак адресов. Условно позиционируем эту схему для небольшой сети.
|
==== VirtualAP ====
|
h4. VirtualAP
|
Например: в торговом центре есть ваши точки доступа. 90% юзеров юзают говносмартфоны и говнопланшеты. Но есть 10% - которым нужно подключить какие-то банковские терминалы и прочие вундервафли, которые не умеют ни впн, ни веб авторизацию и вообще вай фай не умеют )))
|
...
Ставим им тоже вайфай роутер (например - клиентский микротик RB751 - в нем таки уже есть внешняя и внутренняя антены - настраиваем там прием по внешней, раздачу - с внутренней - на другой частоте. Авторизацию на нем - внимание - VPN \!\!\! (это мы уже умеем). Роутер раздает внутри помещения (мощность можно поубавить) опять же на говносматрфоны клиента по ключу (их личная частная сеть). А вундервафлю клиента (банковский терминал и прочие стационарные штуки) вообще включаем проводами к юзерскому роутеру, который уже "авторизован" и раздает невозбранно Инет всем подключенным по - внезапно IPoE ).
|
Для того, чтобы наша (провайдерская) точка доступа могла и хотспот и впн одновременно - придумали Virtual AP - создаем на физическом беспроводном фейсе сколько нужно виртуальных AP - каждая из которых может иметь свой SSID, и типы авторизации (на одной AP включаем hotspot, на другой не включаем и юзаем VPN как обычно), а также наличие/отсутствие своих ключей. Для веб авторизации - оставить видимую беспроводную сетку без ключа. Для остальных извратов - сетку скрыть - ключом закрыть и настраивать индивидуальные роутеры клиентов - чтобы остальных не путать.
|
=== IPoE без Radius ===
''Особенности и причины использования IPoE без RADIUS AAA.''
|
h3. IPoE без Radius
|
|
''Особенности и причины использования IPoE без RADIUS AAA.''
|
Подведем промежуточные итоги:
|
... Если юзать DHCP на Тике без радиус - биллинг вообще ничего не знает о адресах юзера. Схема не кошерная.
Если юзать DHCP на Тике + радиус - биллинг выдает адреса и все почти хорошо, кроме тог, что схема не допилена ). (Знаю людей, которые юзают эту схему с самописным биллингом (они то и пропихнули тему - чтобы тиковцы запилили поддержку DHCP + Opt82 + radius ))
Если юзать хотспот - то все кошерно, но больше подходит для беспроводных клиентов.
|
Поэтому рассмотрим следующие варианты:
|
==== DHCP Ideco + Opt.82 ====
|
h4. DHCP Ideco + Opt.82
|
Итак, Микротик dhcp + radius + Ideco = пока не взлетел.
|
...
Значит нужно юзать DHCP на биллинге - чтобы он таки был в курсе выданных адресов клиентам.
Настройки DHCP Ideco описаны в оффициальной документации.
|
\!\!\! Скрипт обработки событий универсальный - не требует допила - \!\!\! можно юзать '''смешанную схему''' - и VPN и ip авторизацию. Соответственно и настройки NASа в Ideco - ничем не отличаются:
|
\[[Файл:61eea54a757d.png]\]
|
!61eea54a757d.png!
|
(пусть вас не смущают галочки "лишние" - это для универсальности: VPN + radius и схема IPoE без радиус могут работать одновременно\!). Понятно, что радиус и впн можно и не настраивать - IPoE все равно будет работать\!
|
...
Особенности:
В этой схеме - юзеру выставляется тип "авторизации по IP".
|
Так как приходится обходится без радиуса - то биллинг ни черта не в курсе через какой NAS там форвардится юзерский траф - поэтому в "карточке" клиента нужно прописать NAS IP и залочить галочку.
|
\[[Файл:36223c24f223.png]\]
|
!36223c24f223.png!
|
Недостаток схемы - из-за отсутствия радиуса - нет фактического логина/логаута - нет постоянной "актуализации" в каком листе юзер должен находится. Событие "логин" происходит формально один раз. Юзер как бы подключен всегда - нет явных сессий по факту. Трафик рулиться с помощью редких событий - баланс негатив и позитив (так как юзеры платят сразу на неделю или даже месяц). В итоге может происходит "рассинхрон" между биллингом и NAS.
|
...
Пару примеров - почему это может произойти:
- Юзер оплатил деньги. Произошло событие "баланс позитив". В этот момент NAS был в ребуте или связь временно между серверами отсутсвовала (достаточно одну команду всего потерять). И далее юзер может хоть сто раз перезагружаться - он остается в адрес лист негатив. Так же верна и обратная ситуация - денежки кончились у юзера - не прошло событие баланс негатив по любой из причин - и потом ваш юзер может юзать Инет без денег хоть полгода - пока биллинг не перезагрузишь.
* NAS пришлось менять на новый - придется актуализировать вручную адрес-листы.
* Понадобилось восстановить конфиг NASа из бэкапа - также придётся актуализировать вручную адрес-листы.
и т.д.
Понятно - что в жизни потеря команд будет не часто происходить. Но все же периодически рекомендуется делать сверку "вручную" между биллингом и NASом.
Достоинства схемы - простая до безобразия.
Итог - схема без радиуса - это не совсем надежная четкая схема. При небольшом к-ве юзеров можно визуально вручную делать сверку, но при тысячах юзеров - нереально ).
Рекомендуется для относительно небольшой сети.
|
Внезапно можно написать скрипт или программку синхронизации биллинга и NAS и запускать в планировщике по расписанию с заданным интервалом. Тогда можно и для относительно большой сети эту схему применить.
|
==== DHCP Ideco + MAC ====
|
h4. DHCP Ideco + MAC
|
Тоже самое, что и предыдущая схема, только вместо опции82 - юзается MAC - для раздачи адресов.
|
==== IPoE без DHCP и Radius ====
|
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]\]
Не забывайте добавлять имя и адрес своих НАСов в скрипт обработки событий.
|
Прочие скрипты/протоколы/алгоритмы резервирования - выходят за рамки данной статьи.
|
=== "Строгий managment" (services/users/firewall input) ===
При использовании схемы в реальной жизни:
|
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ах резервную схему и отправлять вам смс или мыло на телефончег - что, мол, "ай-яй-яй" )))
|
Такие дела.
|
== Послесловие ==
Вышеописанная схема работает в реальной сети, которая выросла за 5 лет с 20 юзеров до 15 000.
|
h2. Послесловие
|
|
Вышеописанная схема работает в реальной сети, которая выросла за 5 лет с 20 юзеров до 15 000.
|
В статье описаны самые основные базовые моменты. Как известно - существует множество решений одной и той же задачи, и множество инструментов. Я описал лишь одную "узкую тропинку". После ваших тренировок на виртуальном стенде и понимания базовых нюансов - вы можете тюнить систему под особенности вашей инфраструктуры.
|
... Как известно - не существует идеальных схем, но существует множество решений, которые имеют свои плюсы и минусы в каждом конкретном случае, взвесив которые, вы можете выбрать решение своих задач.
Прежде чем задавать вопросы на форумах - воспользуйтесь поиском по документации и форумам. Скорее всего ответы уже существуют.
Особую благодарность выражаю своей дочке, которая всячески "помогала" в написании этой статьи. ))))
Права на статью не существуют.
Перепечатка разрешена чуть более, чем полностью.
Автор не несет никакой ответственности ни за что )
Все замечания и предложения. а также сообщения о найденых ашыпках пишите на форум carbonsoft:
[http://forum3.carbonsoft.ru/forum3/default.aspx?g=posts&t=4850]
|