> > > > делается и на одном порту. Никто не мешает серверу авторизации, принявшему
> > > > через tacacs авторизационный запрос, отправить эккаунтинговый пакет на
> > > > сервер биллинга. Хоть бы и по протоколу radius.
> > > >
> > > Можно. Но это уже хорошо усложнает (ухудшает) общую надежность.
> > > И это как-бы подпорки. Просто радиус это уже и так делает. Как есть.
> >
> > Какой радиус это делает? Какая архитектура системы? Зачем мне
> > лишняя логическая связь? Что я приобрету и что потеряю? Еще раз,
> > там нет однозначности, при столь поверхностном обсуждении.
> >
> По-моему, мы просто потеряли цепочку размышлений.
> Вернемся.
> 1. на местах (на езернете с NAS) стоят сервера аутентификации/авторизации,
> которые действуют по заранее строго определенному сценарию, обеспечивая
> технологический уровень dialup. Клиенты входят и работают.
> 2. в центре стоит сервер аккаунтинга, который коллектит поступающие
> от многочисленных NAS'ов acct-пакеты. Что-то там свое думает, и если
> что, срубает юзера с NAS'а по SNMP.
> Лучше всего пока что под решение такой задачи подходит радиус.
> Та его часть, что отвечает за авторизацию - стандартна.
> Часть аккаунтинга заменена на собственный глюкатор на acct-порту.
> Для этого даже radius патчить не придется, его acct-порт просто
> затыкается за ненадобностью.
Как уже говорилось, есть довольно разумная потребность в кешировании
выделенных IP адресов. Для того, чтобы освобождать выделенный адресс
сервер аутентификации/авторизации (а не эккаунтинга) должен получить
STOP пакет.
Второе соображение, что потеря эккаунтинга, есть не менее огорчительное
явление, чем потеря авторизации, и очень хочеться иметь возможность
буфферизировать эккаунтиг около NAS'а.
Эти два тезиса рушат идилию. И мы сводим авторизацию и эккаунтинг
в одно место. Можно отказаться от кеширования и плюнуть на потерю
эккаунтинга. Но если это _требования_, то обойти их не удасться.
>
> > > > Нет. Продаем услугу. А она может иметь хитрую структуру. С разными
> > > > тарифами в разное время суток и дня недели. Поэтому просто
> > > > складывать/вычитать время не получается. Нужно запускать тарификатор.
> > > >
> > > Представь себе тарификатор, который вызывается каждые 10 сек и работает
> > > исключительно со временем и заданными условиями. Причем он находиться
> > > как-бы в животе самого radius сервера. Он держит все сессии всех
> > > пользователей в памяти, загружая атрибуты/условия в начале сессии и
> > > сохраняя изменения в конце. Он же и принимает всякие решения...
> >
> > А теперь представь себе обратный тарификатор, который живет в том-же
> > животе, но запускается в начале каждой сессии, чтобы из фантиков посчитать
> > timeout. Далее по тексту.
> >
> Зачем timeout? Мы как раз и уходим от него.
Чтобы сшибать более плавно и снизить нагрузку.
> Наверно могу более конкретно изложить, если интересно.
Да я все понял. У меня сейчас работает примерно так, как ты описал.
Только я хочу идти дальше.
Boris.
=============================================================================
"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
