Привет!
Thu Oct 21 04:57, Boris Tyshkiewitch <bvt@zenon.net> wrote:
> > 1. на местах (на езернете с NAS) стоят сервера аутентификации/авторизации,
> > которые действуют по заранее строго определенному сценарию, обеспечивая
> > технологический уровень dialup. Клиенты входят и работают.
> > 2. в центре стоит сервер аккаунтинга, который коллектит поступающие
> > от многочисленных NAS'ов acct-пакеты. Что-то там свое думает, и если
> > что, срубает юзера с NAS'а по SNMP.
> > Лучше всего пока что под решение такой задачи подходит радиус.
> > Та его часть, что отвечает за авторизацию - стандартна.
> > Часть аккаунтинга заменена на собственный глюкатор на acct-порту.
> > Для этого даже radius патчить не придется, его acct-порт просто
> > затыкается за ненадобностью.
>
> Как уже говорилось, есть довольно разумная потребность в кешировании
> выделенных IP адресов. Для того, чтобы освобождать выделенный адресс
> сервер аутентификации/авторизации (а не эккаунтинга) должен получить
> STOP пакет.
>
Во-первых, кешировать IP адрес можно самим NAS. У циско это есть.
Проблема тут может быть только одна - адрес кешируется только в пределах
одного NAS. Т.е. нельзя ставить несколько NAS в одну серию.
Плохо, но не смертельно.
Во-вторых, в этом вопросе пока также нет готового стандартного и красивого
решения, каждый изобретает свой велосипед по-новой. Или уже есть кстати?
И кроме того, ничто не мешает acct-коллектору отрелеить/имитировать stop
пакет куда сказано.
> Второе соображение, что потеря эккаунтинга, есть не менее огорчительное
> явление, чем потеря авторизации, и очень хочеться иметь возможность
> буфферизировать эккаунтиг около NAS'а.
>
Есть множество способов потерять аккаунтинг. На мой взгляд, потеря
коннективности между NAS и учетным центром не является самой популярной
причиной для этого.
Также есть как минимум более одного способа "восстановления" сессии
аккаунтинга. Полностью всю сессию можно потерять только если на всем
ее протяжении отсутствовала коннективити, когда мы не поймали ни start,
ни alive, ни stop. Да и в этом случае можно как-то извратиться, например
небыло конективности больше часа, значит надо попарсить лог-файл сервера
авторизации, это же должно быть крайне редко.
> Эти два тезиса рушат идилию. И мы сводим авторизацию и эккаунтинг
> в одно место. Можно отказаться от кеширования и плюнуть на потерю
> эккаунтинга. Но если это _требования_, то обойти их не удасться.
>
Отнюдь. Всегда найдутся некие workaround.
К тому же, нужно четко представлять масштабы бедствия в случае не учета,
переучета и тп. Например, что лучше, потерять сессию одного-двух клиентов
или перманентно терять одну копейку на всех сессиях из-за кривизны
дочитывания/синхронизации десятков лог-файлов на битых дисках по всей
сети...
> > > А теперь представь себе обратный тарификатор, который живет в том-же
> > > животе, но запускается в начале каждой сессии, чтобы из фантиков посчитать
> > > timeout. Далее по тексту.
> > >
> > Зачем timeout? Мы как раз и уходим от него.
>
> Чтобы сшибать более плавно и снизить нагрузку.
>
> > Наверно могу более конкретно изложить, если интересно.
>
> Да я все понял. У меня сейчас работает примерно так, как ты описал.
> Только я хочу идти дальше.
>
Мы говорим о реалтайме?
Нет необходимости получать из фантиков timeout.
Второе, сшибить нужно ровно тогда, когда у клиента кончилось время,
желательно в ту же секунду.
Как?
В начале сессии клиента мы загружаем его текущий баланс, лучше если это
сразу время в секундах (деньги еще на стоимост поделить и округлить
придеться;), взводим таймер чтоб прерывал нас каждые 10 сек, в каждом
прерывании отнимаем от остатка времени клиента 10 сек. (5 сек., 20 сек),
попутно коллектим acct-пакеты, отрабатываем пропадания связи и пр.,
когда результат <= 0 то срубаем его сессию, сохраняем остаток...
Таким образом мы "растягиваем" время ночью, "ускоряем" в час пик, следим
за границами дозволенного времени, контроллируем мульти-логины, проверяем
номер звонящего, "восстанавливаем" потеряные acct-пакеты и тд., и все это
в одном демоночке, вместо кучи подпорок по всей цепи тарификации.
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
