RADIUS клиент на транзитном шлюзе

[leveler]

На сколько актуальна поддержка протокола RADIUS на транзитном (ОКС-7 + SIP-T) шлюзе? Какие именно атрибуты интересуют для передачи в Access-Request и Accounting-Request?

По вот этому интересно мнение касательно того, каким образом транзитный шлюз будет заполнять поле User-Password/CHAP-Password?

[Deac]

Шлюз транзитный -> RADIUS транзитный -> см. proxy RADIUS

 

P.S. attr_rewrite во FreeRADIUS-е, заполняем любые атрибуты любыми значениями.

[leveler]

То есть, в моей схеме "Шлюз <--> RADIUS-сервер" мне надо ещё и прокси ставить?

[Deac]

Нет.

RADIUS на транзитном шлюзе должен работать в как проксирующий.

 

[leveler]

Вы меня конечно извините, но вашу мысль я не понял.

[Deac]

Учите матчасть.

http://freeradius.org/rfc/rfc2865.html

http://freeradius.org/rfc/rfc2607.txt

Edited November 23, 2010 by Deac

[leveler]

Оформлять тег url вы уже научились. Это хорошо.

А вот своими словами пояснить что к чему, ещё нет.

[Deac]

Мои слова не rfc.

По крайней мере пока. ;)

 

И тэг url форумный движок добавляет сам, правда, правда!

[leveler]

Тогда поясните свой предыдущий пост.

[Deac]

В условиях задачи отсутствует несколько принципиальных моментов, поэтому рассмотрим несколько вариантов.

 

1. Клиентский дивайс сам отправляет запросы к RADIUS-у. Далеко не все дивайсы так умеют.

-- Транзитному узлу достаточно перенаправить эти запросы на parent RADIUS, для этого используется проксирующий RADIUS.

-- Обрабатывать запросы "на месте" или нет - зависит от существующей организации взаимодействия.

Мои посты относились именно к этому варианту.

 

2. Клиентский дивайс не умеет общаться с RADIUS-ом. Наиболее типичный вариант.

-- Транзитный узел сам формирует запросы к parent RADIUS-у, от имени клиентского дивайса.

-- В этом случае наличие RADIUS сервера на транзитном узле не обязательно, достаточно RADIUS клиента.

2.1 Тоже, что и 2., но требуется ещё и учёт на месте.

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

-- В этом случае необходимо наличие как RADIUS сервера, так и RADIUS клиента.

-- Собственный RADIUS сервер, на транзитном узле, работает в проксирующем режиме, т.е. производит необходимые действия с запросом и отправляет его на parent RADIUS.

 

Добавление/заполнение конкретных полей зависит только от логики взаимодействия с собственным биллингом/parent RADIUS-ом.

В случае с FreeRADIUS-ом, нет никаких ограничений, всё добавляется/удаляется/заполняется как требуется.

[leveler]

Вы меня конечно извините, но вы вообще представляете место такого шлюза на сети оператора?

Для меня эта железка - это аналог AS5350, через которую операторы стыкуют свою VoIP сеть с PSTN. Транзитной она называется из-за того, что не терминирует конечных абонентов. Не регистрируется на ней никто, то есть.

Так кой ей функционал RADIUS Proxy?

 

Ей, по сути, и Access-Request'ы слать смысла нет. Но это уже вопросы "не по окладу". Сказано красить в розовый, будем красить. )

 

Отсюда у меня и возникли вопросы к людям, которые эксплуатируют подобные железки. Интересует их мнение по данному вопросу.

[Deac]

Вы можете конкретно показать приходящие запросы от клиентов?

И внятно объяснить что в них не устраивает?

 

Т.е. примерно так:

Auth Request

Есть --> Должно быть

Acc Request

Есть --> Должно быть

 

RADIUS-у по барабану, представляю ли я "место AS3550" в Вашей сети, у него RFC и только RFC.

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

[leveler]

Какие запросы? Вы о чём?

INVITE/SETUP (VoIP/PSTN) в нашу сторону, INVITE/SETUP от нас. Всё.

[Deac]

Какие запросы? Вы о чём?

INVITE/SETUP (VoIP/PSTN) в нашу сторону, INVITE/SETUP от нас. Всё.

Значит см. вариант 2.

Транзитный узел должен сам формировать запросы к RADIUS серверу, на основе информации из REGISTER/INVITE/ACK/BYE/CANCEL.

На каждый event - отдельный запрос, любой софтсвитч, за оч. редким исключением, так умеет.

А вот логика формирования запросов определяется ожиданиями "той" стороны.

[leveler]

Вы мне честно признайтесь. Вы издеваетесь?

[Deac]

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

Как Вам могли поручить то подобное, на что надеялись?