Romka_Kharkov

ТС, напишите в аську, расскажем , поможем. Денег не надо :D

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

Использую:

FreeRADIUS Version 2.0.1 (версия не супер новая, но согласно bugfix листу, до последней никаких изменений касающихся Simul там нет)

SQL: 5.0.33

Проблемы выглядела следующим образом, как я уже описывал выше, на циске я вижу например 10 сессий под одним логином в radacct вижу всего 1 сессию для этого пользователя. Т.е по факту ни какая Simul проверка не срабатывает вовсе и ей даже не пахнет.

Основная проблема оказалась в том, что в checkrad сценарии использовался cisco_l2tp вид NAS, а он в свою очередь совсем на мой взгляд не верно вынимает SNMP OID из моей циски, я не буду грешить на разработчика этого модуля, вполне может быть разность Иосов на железке или время написания сценария вовсе..... по факту ни "cisco" и "cisco_l2tp" мне не подошли для проверки. Пришлось писать свою, писака из меня не очень но и задача не сложная, сделал собственную процедуру проверки наличия клиентов Cisco.

Первый вариант проверки включал в себя обращение по SNMP к Cisco, вытягивания оттуда кол-ва сессий согласно $username. (В моем случае из аргументов подаваемых на checkrad вообще кроме $username ничего выходит не надо.) Данный пример хоть и увенчался успехом чуть посже был признан не работающим, так как при обращении к SNMP я для каждого чека выгребал около 3-4к записей, соответственно чек занимал от 5 до 15 секунд в зависимости от погодных условий на промежутке Cisco <-> Radius. И в итоге я получал TS-Timeout ошибку и клиента повторно пускало на линию, так как проверка не возвращала результата или возвращала его достаточно поздно.

Второй вариант, пришедший на замену первому нес в себе более легкие и для меня по сути странные изминения, я переписал процедуру исключив из нее SNMP вовсе и теперь я сверяю кол-во открытых сессий в radacct путем SQL запроса в локальный SQL сервер, как вы понимаете проверка происходит за считанные секунды.... а иногда и быстрее ))) соответственно нет больше таймаутов, и нет больше повторных авторизаций, в логи по честному стало валить что-то типа:

Как это выглядит сейчас:

"users"

DEFAULT NAS-IP-Address == x.x.x.x, Pool-Name := mypoolname
        Fall-Through = Yes

DEFAULT Simultaneous-Use := 1
        Idle-Timeout := 900,
        Fall-Through = Yes

"clients.conf"

# OUR ADSL NAS 2
client x.x.x.x {
        secret = SECRET
        shortname = NASNAME
        nastype = myown_type
}

Далее модификация для checkrad.pl

sub myown_type {
use DBI;
$username = $ARGV[3];

my $dsn = 'DBI:mysql:xxxxx:localhost';
my $db_user_name = 'xxxxx';
my $db_password = 'xxxxx';
my ($count);
my $dbh = DBI->connect($dsn, $db_user_name, $db_password);

my $sth = $dbh->prepare(qq{SELECT count(*) from radacct where username = '$username' and AcctStopTime = 0});
$sth->execute();

($count) = $sth->fetchrow_array();
$sth->finish();

if ($count >= 1) { $ret = 1; }
if ($count < 1) { $ret = 0; }
$ret;
}

А так же в самом низу надо объявить:

} elsif ($ARGV[0] eq 'cisco_l2tp'){
        $ret = &cisco_l2tp_snmp;

} elsif ($ARGV[0] eq 'myown_type'){
        $ret = &myown_type;

} elsif ($ARGV[0] eq 'mikrotik'){
        $ret = &mikrotik_telnet;

После таких вот изменений, у меня все заработало, как многие успели заметить моя проверка мало чем отличается от стандартного simul_count_query.... но какого-то хрена, этот самый count_query никак не выполнялся при любых шаманских танцах и прочем..... Пояснения я пока искать не стал, но думаю скоро найду :D

В итоге то, чего я планировал добиться случилось, теперь я вижу кучу попыток повторной авторизации от клиентов которые или что-то мутят или криво настроены роутеры .... но уже на самой Cisco я вижу по одной сессии для каждого. Не мало важным является параметр Idle-Timeout , он помогает рубать сессии которые более 15 минут в простое находятся, ибо в момент реконекта, все равно допускается появление 2х сессий на Cisco, но вторая умирает в течении короткого времени.

Ну и не забываем, в моем случае у меня на радиусе всего 1 тип клиентов, если у вас их более одного надо использовать Group в "user" и radgroupcheck табличку для указанной группы. Так же вместо clients.conf описание наса может содержаться в файлике "naslist" но я его так же не использую.

Вот такие танцы с бубном ребята, если что пишите :D

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

kuil, я бы рекомендовал cPanel, не спешите плеваться, я понимаю что вы просите бесплатные, но если панель вам действительно нужна..... (вопрос от myhand), то cPanel за относительно не большие деньги дает прекрасный функционал, не уступающий, а во многом возможно и превосходящий аналоги в сети. Бесплатное можно долго искать, потом столкнутся с проблемой архитектуры, потом перестанут поддерживать разработку, потом еще и еще .... и все это именно по тому, что бесплатно ..... Я с cPanel с 2005 года.. Из платного хостинг-ПО , не встречал более толкового и оперативного суппорта. А в недавнем апдейте есть много фкусных фишек, например поддержка DKIM в панеле пользователя :) Наконец-то люди смогут сами прописывать ключи для своих доменов , пока хорошо это или плохо сказать рано )))) как поведут себя недобросовестные клиенты не ясно ))) но функционал уже есть и он судя по мои тестам работает :D

Вот я уже в очереди за иосом встал посвежее :) Но не думаю что в этом проблема.... У меня конечно не в простое железка стоит , но 50-60% постоянной нагрузки для cisco не должно быть проблемой, ладно бы там у меня 99% фигачило постоянно ..... так и не такие глюки отловить можно :D

P.S: Еще кто-то может что-то сказать по теме, а то она как и ряд других в интернете останется без решения и ответа.... а хотелось бы найти таки решение или разобраться в проблеме как минимум.

Да знаю про клиент, все понятно, тут и пробую, но могу и клиента какогонить на реконект послать, суть особо не меняется.

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

Это вы сейчас о каком параметре?

Multilink PPP у меня отдельные клиенты есть и у них все работает, вот ту есть настройка в Template для MLPP Bundle на самой 7204... там у меня стоит не более 4х и не менее 2х клинтов, те у кого 2 линии нормально поднимают мультилинк, с ними вопросов вообще пока что нет, вопросы с обычными PPPOE клиентами....

Насчет "быстро переподключиться" согласен, но почему в таком случае на самой 7204 сессия продолжает быть активной и мало того, пингуется и мало того, байтики на интерфейсе бегут.....

Я вот за последний час анализа выяснил что у меня такие по какой-то причине происходит "accounting_stop_query", т.е те IP адреса которые были выданы конкретному клиенту и до сих пор висят на циске уже в радиусе помечены как "завершенные сессии" протяженностью 1-2 минута..... то есть по факту, 7204 отправляет STOP пакет на Radius и радиус по честному делает UPDATE в radacct, только вот не ясно или условие не совпадает какое-то или как же так, вот привожу пример:

       accounting_stop_query = " \

          UPDATE ${acct_table2} SET \

             acctstoptime       = '%S', \

             acctsessiontime    = '%{Acct-Session-Time}', \

             acctinputoctets    = '%{%{Acct-Input-Gigawords}:-0}' << 32 | \

                                  '%{%{Acct-Input-Octets}:-0}', \

             acctoutputoctets   = '%{%{Acct-Output-Gigawords}:-0}' << 32 | \

                                  '%{%{Acct-Output-Octets}:-0}', \

             acctterminatecause = '%{Acct-Terminate-Cause}', \

             acctstopdelay      = '%{%{Acct-Delay-Time}:-0}', \

             connectinfo_stop   = '%{Connect-Info}' \

          WHERE acctsessionid   = '%{Acct-Session-Id}' \

          AND username          = '%{SQL-User-Name}' \

          AND nasipaddress      = '%{NAS-IP-Address}'"

В частности:

          WHERE acctsessionid   = '%{Acct-Session-Id}' \

По идее уникальная для каждого соединения.

иду в SQL, делаю Select:

Фактически Одна открытая сессия согласно радиусу, иду на 7204

В действительности один из этих коннектов соответствует сессии которая в radacct (сверяю по IP), теперь я беру иделаю clear interface для интерфейса который НЕ СОВПАДАЕТ с radacct, т.е для интерфейса для которого нет открытой сессии в radacct.

Моя сессия которая описана выше , закрывается !!! какого хрена в общем-то? если совсем другой IP/ID ?!?!?? А вместо нее клиент видимо переконекчивается обратно на линию и я уже получаю новую сессию:

При этом , старая сессия остается на 7204 висеть как ни в чем не бывало + новая сессия вот с новым IP.

Вот что это за мазафака, может ли мне мой Upstream слать какой-то мусор о клиентах который моя 7204 могла бы расценить как STOP Пакеты или что-то в этом роде, как думаете?

---------- Добавлено 17.04.2012 в 21:21 ----------

Еще одно умозаключение приведу, если разобраться в сути проблемы, то в момент вторичной авторизации RAdius должен открыть вторую сессию в SQL, таким образом мой Select по racacct где стоптайм =0 должен выдавать мне >1 строки..... так как сессий больше, но вот как-то это не происходит, у клиента в radacct вроде как всегда 1 запись, отсюда наверное и Simul не срабатывает в принципе? Что-то меня совсем запутало это дело все...

В session {} указан sql, при этом Radutmp отключен вовсе. С базой вроде бы все в порядке.. Странная особенность проблемы заключается в том, что в radacct сессия для клиента одна, а вот "sh users | in username" показывает нуу.. допустим 5-6 :D Причем из них 3-4 адреса пингаются даже... т.е явно на линии....

Simultaneous-Use := 1 , вот это где указывать? Я почитал доки когда пишут в "users", я описал там:

DEFAULT NAS-IP-Address == x.x.x.x, Pool-Name := poolname
        Fall-Through = Yes

DEFAULT Simultaneous-Use := 1
        Fall-Through = Yes

Пробовал аналогичную штуку только Group="groupname" и следом в radgroupreply запись.... тоже не помогло, пробовал в radreply даже добавлять "Simultaneous-Use := 1" для конкретного клиента..... нифига вообще :D :D :D Но теперь у меня возник уже другой вопрос как же произошло так что сессия пингается и в онлайне а о ней нет записи в радиусе? Либо !!! как я вижу по логам , эта сессия была закрыта, на радиусе я получил сигнал "Release IP", т.е на сколько я понимаю 7204 сообщила радиусу о том, что такая-то сессия завершилась... Если подтвердить это логом - все есть.... т.е выглядит весь процесс так:

1) смотрю в терминале sh users, выясняю все интерфейсы по его логину, делаю clear для всех, все ушли с линии, мои радиусы получили "окончание сессии" и сделали "Release IP"

2) жду пару минут...

3) далее последовательность: Login OK / Release IP / Login Ok.... и так несколько раз.... (например 5), в итоге я получаю 5 сесий по этому клиенту в радиусе, 4 из которых закрыты, а 1 открыта и она последняя судя по логу авторизации......

4) Но при этом !!!!! в терминале 7204 продолжают светиться в sh users поднятые интерфейсы для этих клиентов..... и они даже пингаются в некоторых случаях.

У меня такое впечатление , что 7204 засылает какие-то ложные пакеты на радиусы \ либо получает их сама от l2tp upstream.

Интересно, что может быть на стороне клиента такого, что могло бы pppoe Устанавливать во много потоков... ? У них DSL Modems / Routers.... Выглядит как будто клиент из одного места физического рождает 3-4-5 подключений... Как-то так....

Да вот в том то и дело что у меня ))) сижу голову ломаю , уже долго.... :)

Если закинуть его в SQL - выполняется, я получаю сount(*) только это не мешает пользователям повторно логиниться.

На 7204 то ли прошивка старая , то ли что еще , там про pppoe вообще ни слова. Могу скинуть настройки интерфейсов, и.т.п, что конкретно надо? У меня по link там только для multippp есть ограничение на кол-во линий...

Парадокс, а я вчера плакал, что мне электрики аптайм на роутере домашнем сбили (около 250days) :D А тут значит "кто же мне виноват , что сервера по году не перегружаются"...... По идее они и не должны перегружаться и чем больше и дальше тем лучше .... (но без фанатизма конечно) :)

Попробуйте после очистки перезапустить демоны которые могут оставлять файлы в /var, например SQL, apache.... после этого место сразу должно высвободиться ... После перезагрузки каждого демона проверяйте место, как отпустит - сами поймете что за демон занимал его... распространенная проблема.