Если я в правиле сейчас пропишу всю сеть, то оставлю её без интернета :)
Понятно. Но принципиально (для одного клиента) удалось запустить?

 

Ещё просьба сделать изменение скорости и сессии и её сброс по идентификатору, а не номеру порта.
Сделаю. В 0.7-alpha видимо уже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Если я в правиле сейчас пропишу всю сеть, то оставлю её без интернета :)
Понятно. Но принципиально (для одного клиента) удалось запустить?

 

Ещё просьба сделать изменение скорости и сессии и её сброс по идентификатору, а не номеру порта.
Сделаю. В 0.7-alpha видимо уже.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Изменено пользователем vadislaus

Поделиться сообщением


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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чтобы разорвать сессию надо делать 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.

Изменено пользователем Умник

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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.

Изменено пользователем Умник

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В случае с 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 мбит. ;)
Точнее полисер.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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 вручную пробовали запускать?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё есть замечания по 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 помог. Спасибо!

Изменено пользователем 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

VALUE Service-Type lISG-User 101

?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!


Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.


Войти
Подписчики 0