ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] =?KOI8-R?Q?=D3=C5=D2=D4=C9=C6=C9=CB=C1=C3=C9=D1?= =?KOI8-R?Q?_=C2=C9=CC=CC=C9=CE=C7=CF=D7=CF=CA?= =?KOI8-R?Q?_=D3=C9=D3=D4=C5=CD=D9?=



> > > > делается и на одном порту. Никто не мешает серверу авторизации, принявшему
> > > > через 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 http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.