[Умник]

Если я в правиле сейчас пропишу всю сеть, то оставлю её без интернета :)

Понятно. Но принципиально (для одного клиента) удалось запустить?

 

Ещё просьба сделать изменение скорости и сессии и её сброс по идентификатору, а не номеру порта.

Сделаю. В 0.7-alpha видимо уже.

[Max P]

хм... а скрутить вместе с dhcp+radius возможно? скажем если дхцп снял адрес, чтобы lISG тоже это отследил?

[dolphinik]

Если я в правиле сейчас пропишу всю сеть, то оставлю её без интернета :)

Понятно. Но принципиально (для одного клиента) удалось запустить?

 

Ещё просьба сделать изменение скорости и сессии и её сброс по идентификатору, а не номеру порта.

Сделаю. В 0.7-alpha видимо уже.

Да, удалось. Работает неплохо :)

 

[Умник]

а скрутить вместе с dhcp+radius возможно? скажем если дхцп снял адрес, чтобы lISG тоже это отследил?

Все можно. Только нужно понять, какое место в схеме "клиент - DHCP-сервер" занимает маршрутизатор с lISG. Он сам выступает в роли DHCP-сервера или работает релеем?

[Max P]

нет, дхцп сервер отдельно, lISG выдает разрешение на проход трафика с учетом сессии... дхцп на основании опт82 через радиус выдает айпи либо статически, либо из пула... просто хочется однозначной взаимоувязки с айпи и трафиком на этот айпишник... либо я чего то недогоняю? :)

[Умник]

просто хочется однозначной взаимоувязки с айпи и трафиком на этот айпишник...

Зачем для этого нужен DHCP? Увязка и так будет. А чтобы реализовать схему в которой сессия будет стартовать по DHCPREQUEST - необходимо, чтобы lISG находился где-то в цепочке "клиент - DHCP-сервер".

[dolphinik]

Как идут дела с добавлением поддержки COA?

Может быть нужна какая-то помощь?

[Умник]

dolphinik, нет, спасибо, не нужна (пока, во всяком случае). Просто до сегодняшнего дня не удавалось уделять этому достаточно времени. Но на днях планирую закончить.

 

[vadislaus]

Всем привет! Скомпилил, поставил, привязал к биллингу, сессия авторизуется, появляется маршрут на lo интерфейс. Естественно, при этом ничего не работает. Что то еще надо или я туплю?

[Умник]

vadislaus, так задумано. Считается, что у клиента (на его сетевом интерфейсе) серый IP-адрес. Если в атрибуте Framed-IP-Address отдается реальный IP-адрес, то на него создается 1-to-1 (static) NAT запись средствами iptables. Если это не нужно - просто не отдавайте Framed-IP-Address. Иначе - если Вы именно этого и хотели добиться, покажите пожалуйста iptables -nL -t nat.

 

[vadislaus]

Умник, понял. Что посоветуешь, у меня биллинг - UTM, у него атрибут Framed-IP-Address обязательный (в тарифном плане), радиус у него тоже свой. Переходить на FreeRadius или убрать из кода эту задумку (точнее даже не убрать а поставить проверку на "серые адреса)?

 

PS. А кстати, на кой нат и днат белых адресов? Их же можно (я считаю даже нужно) абсолютно нормально пробрасывать. Влан для дома серых IP, влан для белых IP, если лень прописывать руками GVRP нам поможет. Через snmp нужные порты в нужные вланы загоняем. Если денег нет - гостевой vlan с доступом только к ЛК. Или я не прав?

Изменено 9 января, 2010 пользователем vadislaus

[Умник]

vadislaus, в версии 0.6, которая выйдет завтра-послезавтра, я сделаю эту фичу отключаемой (и отключенной по-умолчанию). Фича конечно диковинная довольно-таки. Насчет прямого прописывания IP-адресов - разумно конечно, но в некоторых случаях довольно сложно. Особенно когда намешаны юзеры с серыми адресами и с белыми, причем первых 98%. Хотя дело привычки.

[vadislaus]

Отлично!!!!!!!

Жду с нетерпением.

[vadislaus]

Чтобы разорвать сессию надо делать ISG.pl clear номер сессии? А то в биллинге заблокировал пользователя (у него запущен пинг на ya.ru), прождал час (думал за час ISG спросит у радиуса, можно ли сессии дальше жить), а пинг как шел так и идет. Если вручную сбросить сессию, то больше не авторизует.

Через каталог sys изменил параметры модуля на:

approve_retry_interval = 60

session_max_duration = 60

session_timeout = 60

 

Ничего не изменилось :(

[Умник]

Чтобы разорвать сессию надо делать ISG.pl clear номер сессии?

Разорвать сессию можно так: ISG.pl clear Async# (в новой версии будет Virtual, а не Async - это логично). Вам это удалось сделать вручную?

 

думал за час ISG спросит у радиуса, можно ли сессии дальше жить

Сам он у RADIUS-а спрашивать не полезет (А должен? Сможете показать примеры реализаций?).

 

Если вручную сбросить сессию, то больше не авторизует.

Все верно. В биллинге клиент отключен.

 

approve_retry_interval = 60

session_max_duration = 60

session_timeout = 60

approve_retry_interval (сек.) - время, в течение которого сессия будет находиться в неавторизованном состоянии (потому что пока не ответил RADIUS или ответил, но Access-Reject). Такая сессия называется unapproved. Пока висит unapproved сессия, на RADIUS-сервер запросы не отправляются, клиент никуда не ходит. По истечении этого времени сессия будет удалена и lISG снова попробует обратиться к RADIUS-серверу с Access-Request-ом.

session_max_duration (сек.) - максимальная длительность сессии. Сделано, чтобы в биллинге не было сессий длительностью, например месяц или несколько месяцев, когда клиент постоянно имеет активность. По истечении session_max_duration секунд происходит незаметный для клиента (но заметный для биллинга) Stop и Start сессии (без повторной аутентификации!).

session_timeout (сек.) - разрыв сессии произойдет в случае если клиент бездействует session_timeout секунд.

 

В 0.6-alpha (уже вот-вот) будет CoA (и PoD). Этими средствами сам биллинг может сбросить сессию, когда решит, что это необходимо. UTM это поддерживает?

 

P.S.: Если с CoA/PoD совсем никак - можно сделать периодическую переаутентификацию активных (approved) сессий в 0.7-alpha.

Изменено 10 января, 2010 пользователем Умник

[Умник]

http://www.progtech.ru/~oleg/lISG/

 

Версия 0.6-alpha готова. Из серьезного:

 

* Поддержка CoA и PoD (см. README, спрашивайте если что, если чего-то не хватает)

* Для поиска по hlist теперь используется более быстрая для нашего случая функция jhash_1word (вместо подходящей для общих случаев jhash2)

 

Насчет остального, см. CHANGES.

 

P.S.: Да, не споткнитесь:

* `--session-init name' turned into just `--session-init'. Traffic classification
  (f.e. local traffic and internet traffic) will be done in different way in
  future releases.

Изменено 10 января, 2010 пользователем Умник

[vadislaus]

В случае с UTM есть фишка - rfw клиент. В случае изменения статуса клиента (баланс, изменение тарифного плана и т.п.) биллингом дергается скрипт. В моем случае это ПЛЮС! Этим клиентом я могу в данном случае разрулить, в том числе и вызов ISG.pl с парсингом по IP и в дальнейшем ISG.pl clear, или забить IP в таблицу ipset на первое правило DENY.

 

Как только будет версия 0.6 сразу проверю, отпишу ;)

 

Самое интересное, как поведет себя шейпер при ~1000 клиентов с тарифами 6-16 мбит. ;)

 

[Умник]

в том числе и вызов ISG.pl с парсингом по IP и в дальнейшем ISG.pl clear

В следующей версии сделаю, чтобы можно было сбрасывать юзера по User-Name (то есть по IP-адресу) - не только по Acct-Session-Id и NAS-Port

 

или забить IP в таблицу ipset на первое правило DENY.

А зачем ipset? Не нужна дополнительная нагрузка. lISG сам отлично все заблокирует.

 

Как только будет версия 0.6 сразу проверю, отпишу ;)

Уже есть. Я просто пока все версии -alpha называю. Из соображений осторожности. :) Хотя модуль ядра например очень стабильно работает.

 

Самое интересное, как поведет себя шейпер при ~1000 клиентов с тарифами 6-16 мбит. ;)

Точнее полисер.

[dolphinik]

Есть ещё проблема. Правда больше по дебиану чем ISG.

После make install приходится вручную делать insmod с путём к модулю, чтобы ipstables мог с ним работать. Как можно автоматизировать этот процесс?

[Умник]

dolphinik, модуль по-идее должен автоматически подгружаться, когда вы запускаете iptables -I ... -j ISG.

 

[dolphinik]

atlas@bigz:/lib/modules/2.6.25-2-686/extra# iptables -A FORWARD -s 10.254.0.0/16 -j ISG --session-init

iptables: No chain/target/match by that name.

 

[Умник]

dolphinik, интересно. А modprobe видит модуль (modprobe ipt_ISG)? depmod -a вручную пробовали запускать?

 

[dolphinik]

Ещё есть замечания по CoA.

Для идентификации сервера доступа используется shared secret. В случае с CoA сервер должен принимать запросы от любого хоста и выполнять только те, у которых правильно сформирован authenticator (т.е. пакет не битый и shared ключ клиента совпадает с ключом сервера).

В нашем случае атрибут конфига $cfg{coa_server} по идее не нужен. Как вариант, можно его не удалять, а сделать по-умолчанию пустым(это будет означать, что нужно принимать запросы от любого хоста), и, соответственно, атрибут $cfg{coa_secret} брать из $cfg{radius_secret}.

 

Дальше: RF3576 говорит о том, что для идентификации клиента сервером доступа в пакете нужно указать минимум 2 идентификатора, касающихся сервера и минимум 2 идентификатора, касающихся клиента.

К примеру

NAS-IP-Address

NAS-Identifier

 

User-Name

Acct-Session-Id

 

 

Сейчас буду тестировать дальше.

 

P.S. depmod помог. Спасибо!

Изменено 11 января, 2010 пользователем dolphinik

[Умник]

В нашем случае атрибут конфига $cfg{coa_server} по идее не нужен. Как вариант, можно его не удалять, а сделать по-умолчанию пустым(это будет означать, что нужно принимать запросы от любого хоста), и, соответственно, атрибут $cfg{coa_secret} брать из $cfg{radius_secret}.

Сделаю. Еще я не проверяю shared secret в request-ах. Исправлю либо сегодня ближе к ночи, либо завтра утром.

 

Дальше: RF3576 говорит о том, что для идентификации клиента сервером доступа в пакете нужно указать минимум 2 идентификатора, касающихся сервера и минимум 2 идентификатора, касающихся клиента.

Момент скользкий. По поводу сервера там сказано:

All NAS identification attributes included in a Request message
   MUST match in order for a Disconnect-Request or CoA-Request to be
   successful

То есть если атрибуты есть (не важно, в каком сочетании), то все они должны соответствовать.

Для клиента тоже:

   For session identification attributes, the User-Name and Acct-
   Session-Id Attributes, if included, MUST match

[dolphinik]

Возможно я что-то с чем-то перепутал :)

 

Может добавим в dictionary

VALUE Service-Type lISG-User 101

?

Стало очень сложно идентифицировать запросы на авторизацию от lISG от запросов PPTP/PPPOE серверов, крутящихся на этом же сервере.