[Bah]

После долгих экспериментов с биллингом в нашей сети, я все таки решил перейти на %subj%.

 

Во-первых: Если кто использует подобную связку, то каковы плюсы и минусы подобного решения?

 

Во-вторых: для желающих могу предложить патчи для pppd-2.4.2b1 и icradius-0.18.1, которые позволяют:

1) pppd понимает IP адрес входящего PPTP соединения и использует его как Calling-Station-Id (позволяет привязать пользователя к конкретному локальному адресу)

2) icradius принимая ALIVE пакеты (например, каждую минуту), отписывает в mysql объем принятого и переданного трафика (байт) на данный момент (позволяет следить за трафиком на линии)

3) ну и самое вкусное - в icradius, наряду с атрибутом [Monthly|Weekly|Daily]-Time-Limit (максимальное количество секунд в месяц|неделю|день, которое пользователь может провести на линии) добавлен атрибуты Session-Octets-Limit, Monthly-Bytes-Limit (по аналогии с вышеописанным :-) и Octets-Direction (направление обсчета: суммарный|входящий|исходящий)

 

Все это позволяет, имея один или несколько серверов для PPTP авторизации (мы исходим из расчета 1 сервер на максимум 100 пользователей), иметь единую или распределенную базу пользователей.

 

ЗЫ: веб интерфейс ко всему этому находится в стадии разработки и, скорее всего, будет заточен под наши задачи...

[glush]

минусов я пока не нашел :)

 

по пункту 1 - можно посмотреть на патчик? а лучше на источник :) glush@rasko.ru

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

по пункту 3 - это также имеется во freeradius. в принципе список аттрибутов можно самому расширять правкой словарей.

[Bah]

1) тебе на мыло патчи выслать?

патч для pppd (определение входящего IP при PPTP соединении) базируется на патче Антона Воронина (http://www.chelcom.ru/~anton/projects/pppd-tacacs+radius/). только для версии 2.4.2

Единственный минус - отсутсвие проверки на наличие библиотек procps в системе. Необходимо смотреть Makefile в radius плагине.

 

2) чем тебе радиус не "трафикосчиталка"? ;-)

что касается нетарифицируемых сетей, то мы считаем весь трафик - вот началась сессия и погнали считать до ее окончания. и нам проще, и пользователям понятнее. Просто есть локальные сервисы, доступ к которым идет мимо VPN соединения, т.к. используется внутренняя адресация.

 

3) что касается freeradius - да, оно там есть. но дело не заканчивается просто расширением списка атрибутов, у тебя NAS (в данном случае pppd) должен их поддерживать. В ppp-2.4.2 есть атрибуты аля Session-Octets-Limit и Octets-Direction, вот их и использую.

[Vetal]

я тоже этой связкой пользуюсь. Все проблемы с воровством паролей и трафика отпали.

по мне так лучше и не придумаешь. Единственное но: есть паритет в сетку вышестоящего прова(бесплатный). Тут мимо РРР не пройдешь.

 

а патчики то покажи ;)

а лучше вышли vetal(собака)zer.net.ua

[MaxKr]

После долгих экспериментов с биллингом в нашей сети, я все таки решил перейти на %subj%.

 

Разрешите мне поглядеть на это дело со своей колокольни. Ну-во первых, вот что-что, а, ИМХО, атрибуты от RADIUS-а совсем не зависят. Так что вместо icradius-a легко могло бы быть использовано что-то типа GNU-RADIUS, xtRADIUS или freeradius. У последнего, кстати, очнь своеобразная и достаточно гибкая SQL-схема, рекомендую. Во-вторых, Вы позиционирует решение маршрутизатора на PC? Для кошек оно, AFAIK, не прокатит - отсуствие нужных атрибутов, да и сработают ли они, если сервер вдруг перегрузится... Так что считать надежнее не на роутере (который вообще никакой системной логикой обременен не должен быть по определению), а таки на отдельной машине. Опять же, завтра Вам понадобилось разбить трафик на классы (допустим, часть из него должна отдаваться по пирингу и не считаться клиенту), опять же, на роутере этого делать нельзя. Ну и наконец, MySQL. При alive-ах раз в минуту легко может загнутся, если не сделать сериализатор. Да и вобще - эта СУБД лучший выбор для вэб-разработок, но никак не для учетных систем. Рекомендую посмотреть в сторону Postgre, она в этом отнощении, ИМХО, очень даже ничего (если, конечно, биллинг не корпоративен, там другие веса).

 

Вывод - решение грамотное и наверняка адекватное задаче. Минусы - проблемы реализации и невозможность расширения и усложнения системы. Неуниверсальное решение.

[Vetal]

... если попытаться на РРР поднять циско-айпи-аккаунтинг, то проблемы сами отпадут.

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

тут согласен. Биллинг это святое, и лепить на одну машину все - дурной тон. Разве отсутсвие средств :)

При alive-ах раз в минуту легко может загнутся

сомневаюсь. Это если активных соединений под сотню-две.

Минусы - проблемы реализации и невозможность расширения и усложнения системы. Неуниверсальное решение.

Все в мире совершенствуется. А настроить РРР+радиус+майскуэль намного быстрее любого из виденных мной тарификаторов.

[MaxKr]

... если попытаться на РРР поднять циско-айпи-аккаунтинг' date=' то проблемы сами отпадут.[/quote']

 

ip-accounting есть не только на кошках, но, ИМХО, именно на кошках приятнее использовать NetFlow.

 

Все в мире совершенствуется. А настроить РРР+радиус+майскуэль намного быстрее любого из виденных мной тарификаторов.

 

:) Тут как всегда - Вам шашечки или ехать? если ехать, то надежность должна превалировать над скоростью настройки.

[Vetal]

надеждость связки и обычного тарификатора равны. Пользовался и теми и другими. Но в обичных считалках как пароли защитить? Как бороться с подменой адресов?

[MaxKr]

надеждость связки и обычного тарификатора равны. Пользовался и теми и другими. Но в обичных считалках как пароли защитить? Как бороться с подменой адресов?

 

Пароли шифровать. IP выдавать вместе с началом сессии (как параметр RADIUS-а). :) Только считать по Netflow....

[Bah]

Разрешите мне поглядеть на это дело со своей колокольни. Ну-во первых, вот что-что, а, ИМХО, атрибуты от RADIUS-а совсем не зависят. Так что вместо icradius-a легко могло бы быть использовано что-то типа GNU-RADIUS, xtRADIUS или freeradius. У последнего, кстати, очнь своеобразная и достаточно гибкая SQL-схема, рекомендую.

ICRadius выбран из-за его простоты в настройке и легкой интеграцией с SQL. Его код заточен под MySQL, но переделка под Postgres и др. не займет кучу времени. Плюс ко всему в нем проще было реализовать функции Monthly|Weekly|Daily-Bytes-Limit, что есть один из важнейших аспектов для моей задачи. Кстати, код FreeRadius базируется на ICRadius'е ;-)

 

Во-вторых, Вы позиционирует решение маршрутизатора на PC? Для кошек оно, AFAIK, не прокатит - отсуствие нужных атрибутов, да и сработают ли они, если сервер вдруг перегрузится...

1) А решение под писюк и затачивалось, ибо в домовой сети использовать кошки для аутентификации по VPN (IMHO) не есть дешевое решение.

2) А что может случится при перезагрузке сервера? От этого не застраховано ни одно решение, будь то радиус или обычная считалка трафика

 

Так что считать надежнее не на роутере (который вообще никакой системной логикой обременен не должен быть по определению), а таки на отдельной машине. Опять же, завтра Вам понадобилось разбить трафик на классы (допустим, часть из него должна отдаваться по пирингу и не считаться клиенту), опять же, на роутере этого делать нельзя.

Разбивать трафик на классы, учитывать пиринг и т.п. может понадобиться только мне. Клиентам до этого нет никакого дела - их задача платить с момента включения и до отключения. На данный момент я использую для контроля трафика Argus, но периодически склоняюсь к NetAMS. Нет пока необходимости...

 

Ну и наконец, MySQL. При alive-ах раз в минуту легко может загнутся, если не сделать сериализатор. Да и вобще - эта СУБД лучший выбор для вэб-разработок, но никак не для учетных систем. Рекомендую посмотреть в сторону Postgre, она в этом отнощении, ИМХО, очень даже ничего (если, конечно, биллинг не корпоративен, там другие веса).

Что может послужить причиной загибания MySQL? При 200 клиентах сделать 200 запросов с UPDATE radacct SET AcctInputOctets='xxxx' и тд. это выдержит любой сервер. Использование других SQL серверов только утяжеляет решение, но никак не прибавляет масштабируемости.

 

Вывод - решение грамотное и наверняка адекватное задаче. Минусы - проблемы реализации и невозможность расширения и усложнения системы. Неуниверсальное решение.

IMHO систему можно расширять до безобразия, используя несколько серверов VPN авторизации и нескольких серверов Radius для аккаунтинга. Они будут использовать единую базу пользователей и единую базу аккаунтинга. Для домовой сети большого масштаба - решение весьма недорогое и IMHO очень подходящее.

 

Универсальных решений не бывает... :-)

[MaxKr]

ICRadius выбран из-за его простоты в настройке и легкой интеграцией с SQL. Его код заточен под MySQL, но переделка под Postgres и др. не займет кучу времени. Плюс ко всему в нем проще было реализовать функции Monthly|Weekly|Daily-Bytes-Limit, что есть один из важнейших аспектов для моей задачи. Кстати, код FreeRadius базируется на ICRadius'е ;-)

 

Атрибуты от RADIUS-а мало зависят, больше от NAS-а. А насчет последнего утверждения - я не нашел ничего на www.freeradius.org, что бы могло подтверждать Ваши слова. Все, что там есть - "FreeRADIUS is a variant of the Cistron RADIUS server".

 

1) А решение под писюк и затачивалось, ибо в домовой сети использовать кошки для аутентификации по VPN (IMHO) не есть дешевое решение.

 

Сегодня его нету, завтра оно есть - и снова все переделывать? Неинтересно, поверте. А вот сделать считалку на ip accounting былобы очень неплохим ходом.

 

2) А что может случится при перезагрузке сервера? От этого не застраховано ни одно решение, будь то радиус или обычная считалка трафика

 

Пи пререзагрузке может быть банальное обнуление счетчиков NAS. Как следствие - лимит не сработает. ИМХО, проще сделать отдельную считалку, которая по результатам за сутки отрубала бы перебравших клинтов простым запросом в базу.

 

Разбивать трафик на классы, учитывать пиринг и т.п. может понадобиться только мне. Клиентам до этого нет никакого дела - их задача платить с момента включения и до отключения. На данный момент я использую для контроля трафика Argus, но периодически склоняюсь к NetAMS. Нет пока необходимости...

 

Если так строить схему - то да, большее - только зло. Но это очень неудобно. Как только правила игры меняются, Вам придется пристраивать к этой схеме еще и еще, до тех пор пока не созреете все переделать... :)

 

Что может послужить причиной загибания MySQL? При 200 клиентах сделать 200 запросов с UPDATE radacct SET AcctInputOctets='xxxx' и тд. это выдержит любой сервер. Использование других SQL серверов только утяжеляет решение, но никак не прибавляет масштабируемости.

 

Весь вопрос, за какой промежуток времени эти запросы будут сделаны. А потом, опять же, если Вам в один прекрасный момент захочется еще и вести полные логи, да и выборку по ним делать в базе - поймете прелести более мощных СУБД.

 

IMHO систему можно расширять до безобразия, используя несколько серверов VPN авторизации и нескольких серверов Radius для аккаунтинга. Они будут использовать единую базу пользователей и единую базу аккаунтинга. Для домовой сети большого масштаба - решение весьма недорогое и IMHO очень подходящее.

 

Согласен. Только, опять же, выдержит ли база такого наплыва запросов?

 

Универсальных решений не бывает... :-)

 

Бывают черезчур специализированные и абсолютно неробастные... :)

[MaxKr]

ICRadius выбран из-за его простоты в настройке и легкой интеграцией с SQL. Его код заточен под MySQL, но переделка под Postgres и др. не займет кучу времени. Плюс ко всему в нем проще было реализовать функции Monthly|Weekly|Daily-Bytes-Limit, что есть один из важнейших аспектов для моей задачи. Кстати, код FreeRadius базируется на ICRadius'е ;-)

 

Атрибуты от RADIUS-а мало зависят, больше от NAS-а. А насчет последнего утверждения - я не нашел ничего на www.freeradius.org, что бы могло подтверждать Ваши слова. Все, что там есть - "FreeRADIUS is a variant of the Cistron RADIUS server".

 

1) А решение под писюк и затачивалось, ибо в домовой сети использовать кошки для аутентификации по VPN (IMHO) не есть дешевое решение.

 

Сегодня его нету, завтра оно есть - и снова все переделывать? Неинтересно, поверте. А вот сделать считалку на ip accounting былобы очень неплохим ходом.

 

2) А что может случится при перезагрузке сервера? От этого не застраховано ни одно решение, будь то радиус или обычная считалка трафика

 

Пи пререзагрузке может быть банальное обнуление счетчиков NAS. Как следствие - лимит не сработает. ИМХО, проще сделать отдельную считалку, которая по результатам за сутки отрубала бы перебравших клинтов простым запросом в базу.

 

Разбивать трафик на классы, учитывать пиринг и т.п. может понадобиться только мне. Клиентам до этого нет никакого дела - их задача платить с момента включения и до отключения. На данный момент я использую для контроля трафика Argus, но периодически склоняюсь к NetAMS. Нет пока необходимости...

 

Если так строить схему - то да, большее - только зло. Но это очень неудобно. Как только правила игры меняются, Вам придется пристраивать к этой схеме еще и еще, до тех пор пока не созреете все переделать... :)

 

Что может послужить причиной загибания MySQL? При 200 клиентах сделать 200 запросов с UPDATE radacct SET AcctInputOctets='xxxx' и тд. это выдержит любой сервер. Использование других SQL серверов только утяжеляет решение, но никак не прибавляет масштабируемости.

 

Весь вопрос, за какой промежуток времени эти запросы будут сделаны. А потом, опять же, если Вам в один прекрасный момент захочется еще и вести полные логи, да и выборку по ним делать в базе - поймете прелести более мощных СУБД.

 

IMHO систему можно расширять до безобразия, используя несколько серверов VPN авторизации и нескольких серверов Radius для аккаунтинга. Они будут использовать единую базу пользователей и единую базу аккаунтинга. Для домовой сети большого масштаба - решение весьма недорогое и IMHO очень подходящее.

 

Согласен. Только, опять же, выдержит ли база такого наплыва запросов?

 

Универсальных решений не бывает... :-)

 

Бывают черезчур специализированные и абсолютно неробастные... :)

[Bah]

Атрибуты от RADIUS-а мало зависят, больше от NAS-а. А насчет последнего утверждения - я не нашел ничего на www.freeradius.org, что бы могло подтверждать Ваши слова. Все, что там есть - "FreeRADIUS is a variant of the Cistron RADIUS server".

 

Прошу прощения, здесь я несколько неверно высказался...

Цитата из ФАК по IC-Radius:

5.14

Q: What are the future plans for IC-RADIUS, especially now with FreeRADIUS

A: The code used for IC-RADIUS is the same code thats going into the rlm_sql FreeRADIUS module. The current module scheme for FreeRADIUS does not give quite the flexability as IC-RADIUS. Not only that, but FreeRADIUS is still a ways off production quality. For these reasons IC-RADIUS will continue to be developed for the foreseeable future.

 

А вот сделать считалку на ip accounting былобы очень неплохим ходом

А разве их мало? На мой взгляд достаточно NetAMS или TA-linux для запуска полноценного IP-accounting'а. Решения очень даже рабочии и, опять же, масштабируемые.

 

Весь вопрос, за какой промежуток времени эти запросы будут сделаны. А потом, опять же, если Вам в один прекрасный момент захочется еще и вести полные логи, да и выборку по ним делать в базе - поймете прелести более мощных СУБД.

Из mail-list'ов и по моему опыту - достаточно посылать ALIVE пакеты раз в 5 минут.

Что вы подразумеваете под вести полные логи? Отписывать все сессии (соединения) в базу, аля tcpdump? Если это, то мой argus именно этим и занимается. Информация очень ценная при разборе полетов с особо вредными пользователями. СОРМ не дремлет :-)

 

ЗЫ: Каждый идет своей дорогой... На данном этапе развития сети - мое решение для меня оптимально. Если что-то надо будет кардинально менять, разделять, переделывать - меня это не пугает. Были уже моменты, когда переходили с одного типа оборудования/способа подключения на другой. Собирается тестовая модель, настраивается, а потом поэтапное внедрение... Тяжело, но можно...

[Gris]

А можно мне тоже намылить эти патчики на gris@nxclub.ru?

 

P.S. Было бы еще класно раздобыть патчик для PPPoE, который будет в Caller-ID пихать MAC-адрес входящего на PPPoE-server соединения.

[ol]

Интересная штука. А можно и мне патчики ol@donapex.net

[Serjio]

Netflow при большом трафике теряет пакеты :(

Пользуем ip accounting. На фре ipcad.

 

Интересует другой вопрос, как бороться с большими задержками PPTP на маленьких пакетах, в игры уже не поиграешь. Пинг в Half-Life возрастает с 15 до 100 ms. Правда на кошке не поднимал, а mpd дает вот такой неутишительный результат, даже с перекомпиленным ядром с опцией -O3

[Radik]

мне, плз, если можно - скиньте тоже патчик на мыло

rollo@mail.ru

[Radik]

Да, и еще такой момент - пробовал ли кто-то абсолютно то же самое на цисках - без изменения настроек радиуса все работает так же?

[shs]

Netflow при большом трафике теряет пакеты :(

Пользуем ip accounting. На фре ipcad.

 

Интересует другой вопрос, как бороться с большими задержками PPTP на маленьких пакетах, в игры уже не поиграешь. Пинг в Half-Life возрастает с 15 до 100 ms. Правда на кошке не поднимал, а mpd дает вот такой неутишительный результат, даже с перекомпиленным ядром с опцией -O3

Ну - не знаю

использование pptp + pppd даёт вполне нормальный пинг.

Естественно на FreeBSD.

[Maxim]

Интересно. А можно и мне патчики Max(at)irlan.ru

[Tet]

Раз пошла такая жара...

И мне патчики пожалуста psa(at)ua.fm

[Bah]

В связи с загруженностью, мне некогда рассылать патч всем.

Патч базируется на "TACACS+ and RADIUS plugins for pppd 2.4.1" от Anton Voronin (http://www.chelcom.ru/~anton/projects/pppd-tacacs+radius/).

Т.к. в ppp-2.4.2 есть поддержка RADIUS, то оставалось только добавить кусок кода для определения IP при PPTP соединении. В родном патче заточено под poptop-1.1.3 (в 1.1.4 формат IP адреса чуть другой), пришлось подправить и это.

IMHO мой патч сыроват, т.к. содержит лишние строки из оригинального патча (ну слаб я в Сях ;) и требует описания к применению (установка инклудников от procps). Как-нить сподоблюсь все это оформить и выложу куда-нибудь для скачивания.

[avial]

А есть ли возможность при поднятом VPN-соединении пользоваться ресурсами из внутреннего диапазона не через роутинг VPN. То есть можно ли как-то на клиентских машинах прописать, что через VPN пускать, а что нет?

 

Судя по прочитанному, такое реально только на IPsec поднять. Но у многих еще 98...

[TruthSeeker]

Народ, рекомендую посмотреть в сторону NIBS (http://nibs.net.ua) - биллинг на основе freeradius. Заточен под MySQL, но при желании переделать под любую СУБД можно (меняешь sql-драйвер и запросы в конфиге).

 

Кстати, по поводу стабильности MySQL. Сам я не ее фанат совсем, юзаю FirebirdSQL. Но автор NIBS утверждает, что из за специфики запросов у него MySQL работает в 10 раз быстрее Postgress... В принципе, может он и прав если юзеров немного и интервал прихода ALIVE пакетов не очень маленький... Или вообще без ALIVE. :)

[Bah]

Всем добрый день!

 

По адресу http://khv.net.ru/radius/ лежат следующие файлы:

1) сам ic-radius-0.18.1

2) патч icradius-ha на поддержку нескольких MySQL серверов и прочии фенички

3) мой патч относительно iradius-ha, включая обновление информации о трафике при ALIVE пакетах, лимиты на трафик для пользователя и тп.

 

Савить прям в таком порядке, как написано. Изменения читать в README.HA

Сейчас пробуем залить эти патчи в основную ветку возрожденного ic-radius'а (http://www.icradius.org)

 

Далее:

4) патч к ppp-2.4.2 - определение входящего IP адреса при PPTP соединении и передача его как Called-Station-Id

5) не во всех дистрибудивах Линукса идут инклудники от procps, поэтому присутсвует весь пакет. Компилировать его не надо, просто скинуть необходимуе инклудники в необходимые папки в /usr/include (определиться в процессе компиляции радиус-плагина)

 

Компилируйте на здоровье, ставте и пользуйтесь.

Все вопросы и коментарии - мылом на bahek@setuid.com