Перейти к содержимому
Калькуляторы

Давненько я сюда не заглядывал :).

 

Поделитесь кто пользутся "ISG for Linux" на каком Online абонентов , обьеме трафика , и какие шейперы.

 

Например 500 Online / 300 Mbit / 1,2,5,10 Мбит

Эх блин...

Хочу затестить на реальных юзерах - останавливает только одно - не работает CoA нифига, соотвественно, ни турбо-кнопки, ни ночного увеличения скорости не сделать...

А развитие похоже заглохло...

Жаль, очень жаль...

CoA работает. Правда, не знаю, как с классами трафика - я передаю просто значение шейпера.

Как-то так (у меня в Perl-е):

system ("/bin/echo NAS-IP-Address=$nasip,Acct-Session-Id=$session,Cisco-Account-Info=\"\\\"QU;$speed_out;$burst_out;D;$speed_in;$burst_in\\\"\"|/usr/local/bin/radclient -x $nasip:3799 coa $naspw");

Чудо чудом , а автор пропал в пропасть , талантливый чел , отписался бы хоть , перспективы ограничил или как ?

Насколько я знаю, у Олега сейчас просто нет возможности заниматься развитием. Потихоньку прикручиваем фичи сами, но ничего серьезного - по мелочам больше.

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

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


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

Я снова жив. :)

 

CoA для сервисов допишу на этой неделе. Это должно быть несложно, если мне память не изменяет.

 

Пишите, у кого по-прежнему актуальны старые пробелмы.

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


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

Я снова жив. :)

 

CoA для сервисов допишу на этой неделе. Это должно быть несложно, если мне память не изменяет.

 

Пишите, у кого по-прежнему актуальны старые пробелмы.

 

О! Счастье пришло в наш скромный аул!!! Неужели!!!

Это я действительно радуюсь. :)

Ну, CoA для сервисов - это да, это нужно!

Еще пожелание - для турбо-кнопок удобно было бы передавать через CoA что-то вроде коэффициента скорости для клиентской сессии - передал ночью всем оптом "x2" - и у всех скорости в 2 раза больше, без всякой замены сервисов. Но тут не знаю, насколько это кошерно с точки зрения идеологии.

Еще есть такая штука - у меня вертится на родном радиусе UTM5, и есть такой косяк - статистика по сессиям в биллинг отдается по всем сервисам отдельно + для целой сессии, т.е. трафик суммарный в 2 раза больше оказывается. Хорошо бы это каким-нибудь параметром регулировать, типа $cfg{acct_type} = "session","service" чтобы можно было выбирать кому что нужно.

У меня например разные классы чтобы пиринг отдавать без ограничений скорости, но трафик считать мне индивидуально не надо.

Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке...

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


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

Еще пожелание - для турбо-кнопок удобно было бы передавать через CoA что-то вроде коэффициента скорости для клиентской сессии - передал ночью всем оптом "x2" - и у всех скорости в 2 раза больше, без всякой замены сервисов.

Заменять сервисы будет не нужно. Для простого увеличения скорости нужно отдавать пользователю два сервиса. Один с базовой скоростью, другой - с двойной (ночной). Далее, в зависимости от времени суток, при помощи CoA включать / выключать тот или иной сервис. По-моему это более гибко.

 

Еще есть такая штука - у меня вертится на родном радиусе UTM5, и есть такой косяк - статистика по сессиям в биллинг отдается по всем сервисам отдельно + для целой сессии, т.е. трафик суммарный в 2 раза больше оказывается. Хорошо бы это каким-нибудь параметром регулировать, типа $cfg{acct_type} = "session","service" чтобы можно было выбирать кому что нужно.

У меня например разные классы чтобы пиринг отдавать без ограничений скорости, но трафик считать мне индивидуально не надо.

В HEAD-версии (https://bitbucket.org/sysoleg/lisg/get/master.tar.gz) Вы можете сделать

$cfg{srv}{TESTSERV}{no_accounting} = 1;

Тогда по сервису TESTSERV не будет приходить аккаунтинг. Либо я не так понял задачу?

 

Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке...

Будет реализовано средствами ядра (инфраструктура Netfilter), но без добавления правил в iptables. Таким же образом будет сделан 1-to-1 NAT (он кстати нужен кому-то?). Надобность в некрасивом SubnetSkeleton отпадет.

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


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

В HEAD-версии (https://bitbucket.org/sysoleg/lisg/get/master.tar.gz) Вы можете сделать

$cfg{srv}{TESTSERV}{no_accounting} = 1;

Тогда по сервису TESTSERV не будет приходить аккаунтинг. Либо я не так понял задачу?

Ага, то что нужно!

 

Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке...

Будет реализовано средствами ядра (инфраструктура Netfilter), но без добавления правил в iptables.

Ура-ура, ждем!

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


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

Таким же образом будет сделан 1-to-1 NAT (он кстати нужен кому-то?)

NAToм 1-to-1 пользуемся, специфика сети такая)

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


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

Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке...

Будет реализовано средствами ядра (инфраструктура Netfilter), но без добавления правил в iptables.

Класс! Мне можно будет убрать свои костыли? =)

А как оно будет работать, как -j REDIRECT, на локалхост? Или как DNAT? Имхо правильней будет REDIRECT на локальный веб-сервер, а оттуда уже HTTP 307 (temporary redirect) на страницу авторизации.

Таким же образом будет сделан 1-to-1 NAT (он кстати нужен кому-то?). Надобность в некрасивом SubnetSkeleton отпадет.

Вот это вообще отличная новость.

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


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

Ура! Умник снова с нами! =)

 

Можно фичреквест? =) Хочется какую-нибуть прописываемую "замедлялку" радиус-запросов: например, если сегмент сети "лёг", а потом "воскрес", радиус может не справляться с сотнями акцес-реквестов в секунду, и почти все сессии будут порезаны (X)

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


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

Да, у меня тоже фичреквест!

 

Не логичней ли сделать так, чтобы цепочка -j ISG в iptables работала по другому - делала не DROP неавторизованого трафика, а наоборот ACCEPT авторизованого? А неавторизованый чтобы дальше отправлялся по цепочке?

У меня например есть некое количество ресурсов, которые должны быть доступны всегда, и приходится сначала делать ACCEPT цепочки на эти ресурсы - а их может быть много, и только потом отправлять пакеты в ISG.

Посколько основной трафик идет все же через ISG, то получается, что большинство пакетов впустую ходит через цепочки iptables, впустую расходуя ресурсы.

Если поменять логику, то можно сделать наоборот - сначала трафик отправляется в ISG, где авторизованый акцептится, а только все что осталось идет дальше, а дропнуть его всегда можно успеть.

Верно я рассуждаю?

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


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

Да, у меня тоже фичреквест!

 

Не логичней ли сделать так, чтобы цепочка -j ISG в iptables работала по другому - делала не DROP неавторизованого трафика, а наоборот ACCEPT авторизованого? А неавторизованый чтобы дальше отправлялся по цепочке?

У меня например есть некое количество ресурсов, которые должны быть доступны всегда, и приходится сначала делать ACCEPT цепочки на эти ресурсы - а их может быть много, и только потом отправлять пакеты в ISG.

Используйте ipset. Получится всего одно правило, к тому же очень быстро работающее.

 

-j ISG тоже можно ipset-ом, кстати.

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


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

Реализована активация/деактивация сервисов

 

Много изменений (в частности теперь по-другому задается скорость для сервисов), поэтому перепроверьте свой config.pl.

 

Скачать: https://bitbucket.org/sysoleg/lisg/get/master.tar.gz'>https://bitbucket.org/sysoleg/lisg/get/master.tar.gz

README: https://bitbucket.org/sysoleg/lisg/

 

Важно, чтобы ISGd.pl и модуль ядра были одной и той же версии.

 

Хочется какую-нибуть прописываемую "замедлялку" радиус-запросов

Я думаю будет лучше такую фичу реализовать при помощи iptables на сервере, где стоит RADIUS-сервер (как реализовать такое на FreeBSD не знаю). Как-то так:

 

iptables -A INPUT -p udp --dport 1812 -m limit --limit 10/sec -j ACCEPT
iptables -A INPUT -p udp --dport 1812 -j DROP

 

сначала трафик отправляется в ISG, где авторизованый акцептится, а только все что осталось идет дальше

 

Сделал параметры для модуля ядра:

parm:           tg_permit_action:Xtables action for permitted traffic (0 - CONTINUE (default), 1 - ACCEPT) (uint)
parm:           tg_deny_action:Xtables action for denied traffic (0 - DROP (default), 1 - CONTINUE) (uint)

 

Но лучше эту задачу Вам решить при помощи сервисов. В зависимости от состояния блокировки отдавать тот или иной набор сервисов. В README есть пример.

 

А как оно будет работать, как -j REDIRECT, на локалхост? Или как DNAT?

REDIRECT это и есть DNAT. Куда нужно будет, туда и сможете редиректить, в том числе и на локальные интерфейсы. Впрочем WEB-сервер встраивать в код перлового демона я не считаю целесообразным.

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


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

Можно еще фичреквест? Очень бы хотелось, чтобы классы траффика были не только по подсетям, но и по меткам. Зачем - да хотя бы для удобного шейпинга/полисинга раздельно мир/уа-икс (уа-икс метить по попаданию в ipset/направлению в другой влан, после - заворачивать на lisg).

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


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

Можно еще фичреквест? Очень бы хотелось, чтобы классы траффика были не только по подсетям, но и по меткам. Зачем - да хотя бы для удобного шейпинга/полисинга раздельно мир/уа-икс (уа-икс метить по попаданию в ipset/направлению в другой влан, после - заворачивать на lisg).

Как вариант - какой-нибудь -j ISG --class=x.

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


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

NiTr0, могу сделать lookup по меткам, которые проставлены ранее через -j MARK --set-mark. Это то что нужно?

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


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

Угу, это и имел ввиду, ну либо вариант Abramа.

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


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

Ага, активация сервисов это хорошо, но.

Может все таки сделать возможность передать модулю параметр - коэффициент скорости?

Ну вот сервисы хороши, если нужно реализовать турбо-кнопку - включил юзер турбо, в биллинге в радиус-таблицу добавился ускореный класс, передернули сессию - сессия переавторизовалась, скорость увеличена.

А для ночного ускорения так не удобно - слишком много телодвижений.

Ведь проще сделать, если например ночью дернул modprobe ipt_ISG speed_rate=2 и все, все в 2 раза быстрее.

 

Была мысль еще тупо конфиг подменять - но тогда все сессии дропать придется, чтобы переавторизация на новую скорость прошла, так?

Может сделать перечитывание конфига и автоматическое изменение скоростей так же как с tc.conf, чтобы на лету все менялось?

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


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

seagull,

Вам надо биллинг пилить. lISG тут ни при чем.

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


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

Вам надо биллинг пилить. lISG тут ни при чем.

В моем случае пилить - это значит менять, а это гимор еще тот.

Вот и ищу костыли...

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


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

включил юзер турбо, в биллинге в радиус-таблицу добавился ускореный класс, передернули сессию - сессия переавторизовалась, скорость увеличена.

Более подробно опишите, что Вы делаете. Не совсем ясно, используете ли CoA. Что значит "передернуть сессию"?

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


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

Вам надо биллинг пилить. lISG тут ни при чем.

В моем случае пилить - это значит менять, а это гимор еще тот.

Вот и ищу костыли...

Ну правильно, зачем править свой биллинг? Пусть лучше дядя вместо того, чтобы сделать что-нибудь полезное, сделает для вас костыль.

Сделайте уже в конце-концов у себя скрипт, который будет отсылать CoA с такими скоростями, какие вы хотите. И суньте его куда-нибудь в крон.

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


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

Ещё фичреквест

 

Очень пригодился бы задаваемый в конфиге таймаут для попыток ре-авторизации заблокированных сессий, а то получается, что по первым числам должники с включенным торентом/вируснёй / чем угодно раз в минуту будут насиловать радиус похлеще роутеров, авто-конектящихся к ppp

 

Не проблема, в принципе, изменять approve_retry_interval в модуле, но с конфигом было бы как-то гибче =) Хотя, наверно, если уж оно в модуле, а не в перле, то задавать можно разве что при подгрузке модуля, а если его в любом случае дёргать - нет особого преимущества перед пересборкой... Пардон за поток мыслей =))

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


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

Прошлый фичреквест отменяется, в модуле всё давно предусмотрено как parm =)

 

А вот такая вот фича возможна ли?

 

- Некий параметр в конфиге/триггер модуля, при указании которого при авторизации IP-адреса добавляется маршрут /32 на влан, из которого пришел трафик абонента. Соответственно, при удалении сессии - удалять маршрут.

- Некий параметр, заставляющий isg отдавать радиусу в кач-ве логина и пароля не Ip-адрес, а имя или номер интерфейса, с которого лезет запрос (напри. ethX.100.123 или 100.123)

 

Для чего нужно: попытаться прикрутить терминацию QinQ в схеме влан-на-юзера на тазик с linux_ISG. Причём крайне желательно - без dhcp-событий, на основе которых это сделано на большинстве (да что там, на всех) брасов с ip unnumbered.

 

Для чего это нужно в более растяжимом будущем: на данный момент в схеме l3-connected subscribers в linux_isg устраивает абсолютно ВСЁ, но вот при введении когда-нибуть ipv6 вырисовывается необходимость vlan-per-user.

Ну и конечно когда-нибуть в будущем желательно бы научить isg работать с v6 =)

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


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

Wingman,

У меня тоже была подобного рода идея, но заглянув в код, понял что там всё завязано на ip-адресе и перелопатить нужно будет всё. Решил более простым способом — в демоне ISGd.pl кое-что переделал на моменте авторизации чтобы он вместо IP в поле логина отправлял имя интерфейса. Но это полумера, так как сессия на каждый ip всё равно своя поднимается. Сейчас на тазике 1000 вланов. На каждый влан /29 серых адресов. 1to1 nat. Всё ок. Адреса клиентам раздаются через dhcp-fwd. ISC dhcprelay конкретно тупо укладывает проц на таком кол-ве интерфейсов.

 

По вопросу /32 - клиент ничего не сможет отправить пока у него адреса нету (если только статикой не забито). Поэтому гораздо правильней, я думаю, будет решить этот вопрос на моменте выдачи адреса через dhcp-relay.

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

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


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

alexmern,

Да я так подумал, по большому счёту - прописание /32 можно в перловом демоне элементарно добавить на стадии авторизации; общение с радиусом - тоже в перле зашито, и его можно перековырять

Адреса у нас вообще отдельно раздаются самописным dhcp, поэтому сильно не хочется завязывать брас на dhcp

 

Другое дело, что, в принципе, всё это мне нужно для раздачи ipv6 в будущем, а вот для этого действительно, видимо, нужно сильно перелопачивать сам модуль

Без v6 меня и текущий функционал вполне устраивает

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


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

success story есть у кого? есть данные по нагрузкам?

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.