Abram Опубликовано 24 апреля, 2012 (изменено) · Жалоба Давненько я сюда не заглядывал :). Поделитесь кто пользутся "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"); Чудо чудом , а автор пропал в пропасть , талантливый чел , отписался бы хоть , перспективы ограничил или как ? Насколько я знаю, у Олега сейчас просто нет возможности заниматься развитием. Потихоньку прикручиваем фичи сами, но ничего серьезного - по мелочам больше. Изменено 24 апреля, 2012 пользователем Abram Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 1 мая, 2012 · Жалоба Я снова жив. :) CoA для сервисов допишу на этой неделе. Это должно быть несложно, если мне память не изменяет. Пишите, у кого по-прежнему актуальны старые пробелмы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 2 мая, 2012 · Жалоба Я снова жив. :) CoA для сервисов допишу на этой неделе. Это должно быть несложно, если мне память не изменяет. Пишите, у кого по-прежнему актуальны старые пробелмы. О! Счастье пришло в наш скромный аул!!! Неужели!!! Это я действительно радуюсь. :) Ну, CoA для сервисов - это да, это нужно! Еще пожелание - для турбо-кнопок удобно было бы передавать через CoA что-то вроде коэффициента скорости для клиентской сессии - передал ночью всем оптом "x2" - и у всех скорости в 2 раза больше, без всякой замены сервисов. Но тут не знаю, насколько это кошерно с точки зрения идеологии. Еще есть такая штука - у меня вертится на родном радиусе UTM5, и есть такой косяк - статистика по сессиям в биллинг отдается по всем сервисам отдельно + для целой сессии, т.е. трафик суммарный в 2 раза больше оказывается. Хорошо бы это каким-нибудь параметром регулировать, типа $cfg{acct_type} = "session","service" чтобы можно было выбирать кому что нужно. У меня например разные классы чтобы пиринг отдавать без ограничений скорости, но трафик считать мне индивидуально не надо. Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 2 мая, 2012 · Жалоба Еще пожелание - для турбо-кнопок удобно было бы передавать через 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 отпадет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 2 мая, 2012 · Жалоба В HEAD-версии (https://bitbucket.org/sysoleg/lisg/get/master.tar.gz) Вы можете сделать $cfg{srv}{TESTSERV}{no_accounting} = 1; Тогда по сервису TESTSERV не будет приходить аккаунтинг. Либо я не так понял задачу? Ага, то что нужно! Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке... Будет реализовано средствами ядра (инфраструктура Netfilter), но без добавления правил в iptables. Ура-ура, ждем! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
C@T Опубликовано 2 мая, 2012 · Жалоба Таким же образом будет сделан 1-to-1 NAT (он кстати нужен кому-то?) NAToм 1-to-1 пользуемся, специфика сети такая) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 3 мая, 2012 · Жалоба Ну еще хочется чтобы L4redirect пошел в продакшн - тут народ вроде делал патчи, но хочется как-то в основной ветке... Будет реализовано средствами ядра (инфраструктура Netfilter), но без добавления правил в iptables. Класс! Мне можно будет убрать свои костыли? =) А как оно будет работать, как -j REDIRECT, на локалхост? Или как DNAT? Имхо правильней будет REDIRECT на локальный веб-сервер, а оттуда уже HTTP 307 (temporary redirect) на страницу авторизации. Таким же образом будет сделан 1-to-1 NAT (он кстати нужен кому-то?). Надобность в некрасивом SubnetSkeleton отпадет. Вот это вообще отличная новость. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 3 мая, 2012 · Жалоба Ура! Умник снова с нами! =) Можно фичреквест? =) Хочется какую-нибуть прописываемую "замедлялку" радиус-запросов: например, если сегмент сети "лёг", а потом "воскрес", радиус может не справляться с сотнями акцес-реквестов в секунду, и почти все сессии будут порезаны (X) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 4 мая, 2012 · Жалоба Да, у меня тоже фичреквест! Не логичней ли сделать так, чтобы цепочка -j ISG в iptables работала по другому - делала не DROP неавторизованого трафика, а наоборот ACCEPT авторизованого? А неавторизованый чтобы дальше отправлялся по цепочке? У меня например есть некое количество ресурсов, которые должны быть доступны всегда, и приходится сначала делать ACCEPT цепочки на эти ресурсы - а их может быть много, и только потом отправлять пакеты в ISG. Посколько основной трафик идет все же через ISG, то получается, что большинство пакетов впустую ходит через цепочки iptables, впустую расходуя ресурсы. Если поменять логику, то можно сделать наоборот - сначала трафик отправляется в ISG, где авторизованый акцептится, а только все что осталось идет дальше, а дропнуть его всегда можно успеть. Верно я рассуждаю? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 6 мая, 2012 · Жалоба Да, у меня тоже фичреквест! Не логичней ли сделать так, чтобы цепочка -j ISG в iptables работала по другому - делала не DROP неавторизованого трафика, а наоборот ACCEPT авторизованого? А неавторизованый чтобы дальше отправлялся по цепочке? У меня например есть некое количество ресурсов, которые должны быть доступны всегда, и приходится сначала делать ACCEPT цепочки на эти ресурсы - а их может быть много, и только потом отправлять пакеты в ISG. Используйте ipset. Получится всего одно правило, к тому же очень быстро работающее. -j ISG тоже можно ipset-ом, кстати. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 12 мая, 2012 · Жалоба Реализована активация/деактивация сервисов Много изменений (в частности теперь по-другому задается скорость для сервисов), поэтому перепроверьте свой 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-сервер встраивать в код перлового демона я не считаю целесообразным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 мая, 2012 · Жалоба Можно еще фичреквест? Очень бы хотелось, чтобы классы траффика были не только по подсетям, но и по меткам. Зачем - да хотя бы для удобного шейпинга/полисинга раздельно мир/уа-икс (уа-икс метить по попаданию в ipset/направлению в другой влан, после - заворачивать на lisg). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 12 мая, 2012 · Жалоба Можно еще фичреквест? Очень бы хотелось, чтобы классы траффика были не только по подсетям, но и по меткам. Зачем - да хотя бы для удобного шейпинга/полисинга раздельно мир/уа-икс (уа-икс метить по попаданию в ipset/направлению в другой влан, после - заворачивать на lisg). Как вариант - какой-нибудь -j ISG --class=x. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 13 мая, 2012 · Жалоба NiTr0, могу сделать lookup по меткам, которые проставлены ранее через -j MARK --set-mark. Это то что нужно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 мая, 2012 · Жалоба Угу, это и имел ввиду, ну либо вариант Abramа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 18 мая, 2012 · Жалоба Ага, активация сервисов это хорошо, но. Может все таки сделать возможность передать модулю параметр - коэффициент скорости? Ну вот сервисы хороши, если нужно реализовать турбо-кнопку - включил юзер турбо, в биллинге в радиус-таблицу добавился ускореный класс, передернули сессию - сессия переавторизовалась, скорость увеличена. А для ночного ускорения так не удобно - слишком много телодвижений. Ведь проще сделать, если например ночью дернул modprobe ipt_ISG speed_rate=2 и все, все в 2 раза быстрее. Была мысль еще тупо конфиг подменять - но тогда все сессии дропать придется, чтобы переавторизация на новую скорость прошла, так? Может сделать перечитывание конфига и автоматическое изменение скоростей так же как с tc.conf, чтобы на лету все менялось? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 18 мая, 2012 · Жалоба seagull, Вам надо биллинг пилить. lISG тут ни при чем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 18 мая, 2012 · Жалоба Вам надо биллинг пилить. lISG тут ни при чем. В моем случае пилить - это значит менять, а это гимор еще тот. Вот и ищу костыли... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Умник Опубликовано 18 мая, 2012 · Жалоба включил юзер турбо, в биллинге в радиус-таблицу добавился ускореный класс, передернули сессию - сессия переавторизовалась, скорость увеличена. Более подробно опишите, что Вы делаете. Не совсем ясно, используете ли CoA. Что значит "передернуть сессию"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 19 мая, 2012 · Жалоба Вам надо биллинг пилить. lISG тут ни при чем. В моем случае пилить - это значит менять, а это гимор еще тот. Вот и ищу костыли... Ну правильно, зачем править свой биллинг? Пусть лучше дядя вместо того, чтобы сделать что-нибудь полезное, сделает для вас костыль. Сделайте уже в конце-концов у себя скрипт, который будет отсылать CoA с такими скоростями, какие вы хотите. И суньте его куда-нибудь в крон. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 9 июня, 2012 · Жалоба Ещё фичреквест Очень пригодился бы задаваемый в конфиге таймаут для попыток ре-авторизации заблокированных сессий, а то получается, что по первым числам должники с включенным торентом/вируснёй / чем угодно раз в минуту будут насиловать радиус похлеще роутеров, авто-конектящихся к ppp Не проблема, в принципе, изменять approve_retry_interval в модуле, но с конфигом было бы как-то гибче =) Хотя, наверно, если уж оно в модуле, а не в перле, то задавать можно разве что при подгрузке модуля, а если его в любом случае дёргать - нет особого преимущества перед пересборкой... Пардон за поток мыслей =)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 15 июня, 2012 · Жалоба Прошлый фичреквест отменяется, в модуле всё давно предусмотрено как 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 =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexmern Опубликовано 15 июня, 2012 (изменено) · Жалоба Wingman, У меня тоже была подобного рода идея, но заглянув в код, понял что там всё завязано на ip-адресе и перелопатить нужно будет всё. Решил более простым способом — в демоне ISGd.pl кое-что переделал на моменте авторизации чтобы он вместо IP в поле логина отправлял имя интерфейса. Но это полумера, так как сессия на каждый ip всё равно своя поднимается. Сейчас на тазике 1000 вланов. На каждый влан /29 серых адресов. 1to1 nat. Всё ок. Адреса клиентам раздаются через dhcp-fwd. ISC dhcprelay конкретно тупо укладывает проц на таком кол-ве интерфейсов. По вопросу /32 - клиент ничего не сможет отправить пока у него адреса нету (если только статикой не забито). Поэтому гораздо правильней, я думаю, будет решить этот вопрос на моменте выдачи адреса через dhcp-relay. Изменено 15 июня, 2012 пользователем alexmern Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 15 июня, 2012 · Жалоба alexmern, Да я так подумал, по большому счёту - прописание /32 можно в перловом демоне элементарно добавить на стадии авторизации; общение с радиусом - тоже в перле зашито, и его можно перековырять Адреса у нас вообще отдельно раздаются самописным dhcp, поэтому сильно не хочется завязывать брас на dhcp Другое дело, что, в принципе, всё это мне нужно для раздачи ipv6 в будущем, а вот для этого действительно, видимо, нужно сильно перелопачивать сам модуль Без v6 меня и текущий функционал вполне устраивает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ichthyandr Опубликовано 29 августа, 2012 · Жалоба success story есть у кого? есть данные по нагрузкам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...