RouterOS DHCP + Freeradius - Очереди

Я пытаюсь сделать шейпинг через DHCP и столкнулся с той же проблемой. Думаю, есть ошибка в обработке DHCP на стороне Mikrotik. Если станция отправляет запрос в первый раз, у Mikrotik нет аренды, и он корректно отправляет запросы на RADIUS. Если станция отключается и повторно отправляет DHCP-запрос или обновляет аренду, Mikrotik пытается проверить свою базу данных на наличие статических аренд. Если он находит любую аренду, то повторно запрос к RADIUS не отправляется. Так нужно делать только для аренд от RADIUS. Какие есть обходные решения? Отправлять Session-Timeout. Mikrotik по умолчанию считает его неограниченным? Регулярно чистить всю базу данных аренд. Скрипт для ручной очистки конкретной аренды, вызванный скриптом аренды. Попросить Mikrotik исправить баг?

Номер 1 работает для моих 2000 клиентов… Я бы сказал, что пункты 2 и 3 не нужны, если выполняется пункт 1. Пункт 4 тоже необязателен, потому что система работает так, как задумано. Аутентификация отделена от авторизации. Если RADIUS не указывает время сессии, DHCP-сервер использует MAC-аутентификацию для идентификации устройства. Если в ответе авторизации от RADIUS нет ограничений, пользователь или устройство не имеют ограничений. У DHCP-сервера есть собственное понятие времени аренды (Lease Time), которое не связано с авторизацией.

Так что, когда клиент без ограничений пытается продлить аренду, DHCP-сервер смотрит в таблицу ограничений и говорит: «00:11:22:33:44:55» не вышел за пределы разрешённого времени, продли аренду. Если RADIUS возвращает Session-Timeout, DHCP-сервер знает, что этот MAC-адреса аутентифицирован и авторизован на следующие ${Session-Timeout} секунд. Если устройство запрашивает продление аренды, DHCP проверяет свою таблицу и видит: «этот MAC-адрес уже аутентифицирован и авторизован до ${time}». Если новое время аренды позволит устройству получить доступ дольше, чем $time, DHCP должен снова запросить у RADIUS информацию об авторизации устройства.

С PPP, если не указать Session-Timeout или другие ограничения, пользователь может оставаться подключённым вечно и никогда не проходить повторную аутентификацию. Тут разницы нет. Просто концепция стандартного времени аренды в DHCP вводит людей в заблуждение.

lambert Спасибо за подробности. Мы реализовали Session-Timeout, и, судя по всему, он работает именно так, как нам нужно! Попробуем использовать Mikrotik-Address-List, мы уже делали это для PPP-серверов, так что это довольно просто. Меня немного сбивает с толку, что в официальной документации этот параметр отсутствует: http://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server

Какие атрибуты ответа вы возвращаете? У нас это работает круглосуточно, без сбоев. Ниже приведены атрибуты, которые мы используем для всех. Клиенты с фиксированными IP-адресами также получают атрибут Framed-IP из таблицы radreply.

mysql> select * from radgroupreply where groupname = "1MbCustomers";
+-----+--------------+-----------------------+----+--------------+
| id  | groupname    | attribute             | op | value        |
+-----+--------------+-----------------------+----+--------------+
|  67 | 1MbCustomers | Mikrotik-Address-List | =  | 1MbCustomers |
|  66 | 1MbCustomers | Framed-Pool           | =  | CustPub      |
| 107 | 1MbCustomers | Session-Timeout       | =  | 7200         |
+-----+--------------+-----------------------+----+--------------+

Если клиент переходит на другой тариф, мы переводим его в другую группу, и связанный список адресов возвращается при следующем обновлении аренды. После получения нового лиза все новые подключения сопоставляются со списком адресов в правилах mangle. Эти новые подключения затем регулируются правилами очередей (queue tree).

Существующие же длительные подключения не затрагиваются, если только IP не меняется и, соответственно, соединение не прерывается. Проверяете ли вы, находится ли динамическая запись клиента в /ip firewall address-list и изменялась ли она?

Сейчас мы используем версию 6.18. Эта проблема касается обработки атрибута radius. Если мы установим атрибут в какое-то значение, он останется в этом состоянии до тех пор, пока мы не зададим новое значение. Например, мы отправляем из Radius:

Framed-IP-Address = 172.16.1.1  
Mikrotik-Address-List = hotline  
Session-Timeout = 3600

Этот адрес остаётся в фильтре hotline. Теперь мы удалили пользователя из списка hotline:

Framed-IP-Address = 172.16.1.1  
Session-Timeout = 3600

Но список адресов «hotline» всё ещё держит IP 172.16.1.1, пока не отключишь устройство! Каждое обновление аренды сохраняет его в списке. Единственный способ динамически убрать атрибут — указать новое значение:

Framed-IP-Address = 172.16.1.1  
Mikrotik-Address-List = allow  
Session-Timeout = 3600

Мне кажется, это неочевидная работа с атрибутами radius. Если мы задаём Session-Timeout, то логично ожидать, что все атрибуты автоматически истекут — так же, как и аренда DHCP. Но на самом деле нужно подать новое значение для какого-то атрибута, чтобы «заменить» старое.

Mikrotik DHCP + Radius используется многими в мире, думаю. Лучше обновить базу знаний, чем вносить изменения в софт. Если команда Mikrotik даст доступ, я могу написать заметки на вики.

Интересуюсь списком изменений для ROS версии 6.23. Что нового в 6.23 (2014-12-04 14:46):
dhcpv4 server – исправлено добавление списков адресов из radius. Это то самое исправление, о котором я упоминал выше, или что-то другое? Планирую обновиться с 6.18 на новую версию и расширить настройку DHCP+Radius.

Это действительно грустная история про процесс разработки ПО для ROS. Каждое обновление исправляет баги, которые появились раньше, и при этом создаёт новые. Так что стабильной версии на долгое время пока нет. Кстати, у нас очень хорошо работает связка DHCP + Freeradius + очереди. Сейчас я пытаюсь найти способ мониторинга загрузки очередей. Можно использовать и SNMP, и Tools -> Graphing. Но оба метода работают только в течение срока аренды DHCP. Если абонент переподключается по какой-то причине, система меняет SNMP номер очереди, и счётчики становятся неизвестными. Я заметил, что удаление простой очереди автоматически убирает вручную добавленную команду /tool graphing queue add simple-queue=XXXX. Поэтому локальные графики тоже становятся неизвестными. Вероятно, это ожидаемое поведение для обоих методов. Но есть ли способ мониторить статистику для динамических очередей? Я подумываю о автоматическом создании и поддержании очередей через скрипт лизинга.