Сейчас багрепорт доступен для всех клиентов.ds писал(а):А у нас даже о баге не скажешь, если хотлайна нет в подписке
UTM5 + полноценный RADIUS
Не имел дело с котами...ds писал(а): Атрибутами, например вот так
Cisco-AVPair := "ip:addr-pool=1",
Назначем пул
Session-Timeout := 180,
Время сессии
Cisco-AVPair := "lcp:interface-config=ip policy route-map net172-proxy"
Заворачиваем на прокси, с переадресацией на ошибку по условию
Насколько я понял имеется ввиду, что пул задан на маршрутизаторе, а в атрибутах мы просто передаем ID пула? Если это так, то такое "решение" мало кому нужно.
Может быть, удобно в такие пулы отправлять заблокированных по балансу, или за вирусы например. Только для удобства, не более.Arti писал(а):Не имел дело с котами...ds писал(а): Атрибутами, например вот так
Cisco-AVPair := "ip:addr-pool=1",
Назначем пул
Session-Timeout := 180,
Время сессии
Cisco-AVPair := "lcp:interface-config=ip policy route-map net172-proxy"
Заворачиваем на прокси, с переадресацией на ошибку по условию
Насколько я понял имеется ввиду, что пул задан на маршрутизаторе, а в атрибутах мы просто передаем ID пула? Если это так, то такое "решение" мало кому нужно.
Можно и из пула биллинга выдавать, пошаманить только немного нужно. Будет время, попробую.
Нет пул задается в утмке. Если я использую обычный радиус то все работает нормально айпи выдаются динамически. Когда прикрутил фрирадиус подключение не происходит пишет что не может получить айпи адресс.(фрирадиус использлвал для того чтоб осуществлялась аутинтификация с AD)Arti писал(а):Не имел дело с котами...ds писал(а): Атрибутами, например вот так
Cisco-AVPair := "ip:addr-pool=1",
Назначем пул
Session-Timeout := 180,
Время сессии
Cisco-AVPair := "lcp:interface-config=ip policy route-map net172-proxy"
Заворачиваем на прокси, с переадресацией на ошибку по условию
Насколько я понял имеется ввиду, что пул задан на маршрутизаторе, а в атрибутах мы просто передаем ID пула? Если это так, то такое "решение" мало кому нужно.
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
, только сделать урфаклиента модулем для фрирадиуса.-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
есть такая мысль...
На самом деле если вчитаться как работает "штатное" динамическое распределение адресов - то возникает множество вопросов, о том на сколько ЭТО оптимально.
Зато относительно легко можно повторить своими силами.
Идея вот в чём:
Нужно написать свой модуль для фри радиуса или использовать например rlm_perl.
Логика банальна:
Все тоже что и в rlm_sql. Нужно только дополнительно делать вот что:
Если у данного Л/С есть привязанная ip-группа из пула/пулов - выдать этот ip-адрес.
Если нет - найти свободную группу и дернуть урфа-функцию на привязку IP-группы. Выдать клиенту привязанный адрес.
Для минимизации вероятности вызова урфа-функци - нужно стараться удалять группы только когда действительно это необходимо.
Т.е. дергать урфа-функцию на удаление группы по стоп-пакету - не самая хорошая идея - т.к. придется гарантированно дёргать функцию на привязку при повторном логине. Как при этом осуществляется взаимодействие с "тарификатором" - остается только гадать, но лучше не напрягать систему лишний раз.
Как вариант использовать специальную таблицу, содержащую все ip адреса пула. После завершения урфа на привязку адреса - метить соответствующий ip как занятый. По крону или при привязке группы, или старте сессии искать не используемые группы - вызывать скрипт удаления группы и метить их как свободные.
Для отдельной таблицы с адресами можно использовать блокировки для предупреждения возникновения условий гонок.
На самом деле если вчитаться как работает "штатное" динамическое распределение адресов - то возникает множество вопросов, о том на сколько ЭТО оптимально.
Зато относительно легко можно повторить своими силами.
Идея вот в чём:
Нужно написать свой модуль для фри радиуса или использовать например rlm_perl.
Логика банальна:
Все тоже что и в rlm_sql. Нужно только дополнительно делать вот что:
Если у данного Л/С есть привязанная ip-группа из пула/пулов - выдать этот ip-адрес.
Если нет - найти свободную группу и дернуть урфа-функцию на привязку IP-группы. Выдать клиенту привязанный адрес.
Для минимизации вероятности вызова урфа-функци - нужно стараться удалять группы только когда действительно это необходимо.
Т.е. дергать урфа-функцию на удаление группы по стоп-пакету - не самая хорошая идея - т.к. придется гарантированно дёргать функцию на привязку при повторном логине. Как при этом осуществляется взаимодействие с "тарификатором" - остается только гадать, но лучше не напрягать систему лишний раз.
Как вариант использовать специальную таблицу, содержащую все ip адреса пула. После завершения урфа на привязку адреса - метить соответствующий ip как занятый. По крону или при привязке группы, или старте сессии искать не используемые группы - вызывать скрипт удаления группы и метить их как свободные.
Для отдельной таблицы с адресами можно использовать блокировки для предупреждения возникновения условий гонок.
В принципе все правильно, есть пара уточнений, фрирадиус умеет хранить выданные ip, таблица по дефолту называется у него radutmp.Arti писал(а):есть такая мысль...
На самом деле если вчитаться как работает "штатное" динамическое распределение адресов - то возникает множество вопросов, о том на сколько ЭТО оптимально.
Зато относительно легко можно повторить своими силами.
Идея вот в чём:
Нужно написать свой модуль для фри радиуса или использовать например rlm_perl.
Логика банальна:
Все тоже что и в rlm_sql. Нужно только дополнительно делать вот что:
Если у данного Л/С есть привязанная ip-группа из пула/пулов - выдать этот ip-адрес.
Если нет - найти свободную группу и дернуть урфа-функцию на привязку IP-группы. Выдать клиенту привязанный адрес.
Для минимизации вероятности вызова урфа-функци - нужно стараться удалять группы только когда действительно это необходимо.
Т.е. дергать урфа-функцию на удаление группы по стоп-пакету - не самая хорошая идея - т.к. придется гарантированно дёргать функцию на привязку при повторном логине. Как при этом осуществляется взаимодействие с "тарификатором" - остается только гадать, но лучше не напрягать систему лишний раз.
Как вариант использовать специальную таблицу, содержащую все ip адреса пула. После завершения урфа на привязку адреса - метить соответствующий ip как занятый. По крону или при привязке группы, или старте сессии искать не используемые группы - вызывать скрипт удаления группы и метить их как свободные.
Для отдельной таблицы с адресами можно использовать блокировки для предупреждения возникновения условий гонок.
Выдавать динамические IP следует если от радиуса не пришел ip, из пула прописанного на самой циске, а после этого радиус дергает скрипт который вызывает урфу, помоему это можно натравить штатными средствами радиуса на старт аккаунтинг пакет.