Jump to content
Калькуляторы

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Нет.

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

Auth Request

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

Acc Request

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
Какие запросы? Вы о чём?

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this