leveler Опубликовано 17 ноября, 2010 · Жалоба На сколько актуальна поддержка протокола RADIUS на транзитном (ОКС-7 + SIP-T) шлюзе? Какие именно атрибуты интересуют для передачи в Access-Request и Accounting-Request? По вот этому интересно мнение касательно того, каким образом транзитный шлюз будет заполнять поле User-Password/CHAP-Password? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 19 ноября, 2010 · Жалоба Шлюз транзитный -> RADIUS транзитный -> см. proxy RADIUS P.S. attr_rewrite во FreeRADIUS-е, заполняем любые атрибуты любыми значениями. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 22 ноября, 2010 · Жалоба То есть, в моей схеме "Шлюз <--> RADIUS-сервер" мне надо ещё и прокси ставить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 22 ноября, 2010 · Жалоба Нет. RADIUS на транзитном шлюзе должен работать в как проксирующий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 23 ноября, 2010 · Жалоба Вы меня конечно извините, но вашу мысль я не понял. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 23 ноября, 2010 (изменено) · Жалоба Учите матчасть. http://freeradius.org/rfc/rfc2865.html http://freeradius.org/rfc/rfc2607.txt Изменено 23 ноября, 2010 пользователем Deac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 23 ноября, 2010 · Жалоба Оформлять тег url вы уже научились. Это хорошо. А вот своими словами пояснить что к чему, ещё нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 23 ноября, 2010 · Жалоба Мои слова не rfc. По крайней мере пока. ;) И тэг url форумный движок добавляет сам, правда, правда! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 24 ноября, 2010 · Жалоба Тогда поясните свой предыдущий пост. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 24 ноября, 2010 · Жалоба В условиях задачи отсутствует несколько принципиальных моментов, поэтому рассмотрим несколько вариантов. 1. Клиентский дивайс сам отправляет запросы к RADIUS-у. Далеко не все дивайсы так умеют. -- Транзитному узлу достаточно перенаправить эти запросы на parent RADIUS, для этого используется проксирующий RADIUS. -- Обрабатывать запросы "на месте" или нет - зависит от существующей организации взаимодействия. Мои посты относились именно к этому варианту. 2. Клиентский дивайс не умеет общаться с RADIUS-ом. Наиболее типичный вариант. -- Транзитный узел сам формирует запросы к parent RADIUS-у, от имени клиентского дивайса. -- В этом случае наличие RADIUS сервера на транзитном узле не обязательно, достаточно RADIUS клиента. 2.1 Тоже, что и 2., но требуется ещё и учёт на месте. -- Транзитный узел сам формирует запросы к собственному RADIUS серверу, используя RADIUS клиент, от имени клиентского дивайса. -- В этом случае необходимо наличие как RADIUS сервера, так и RADIUS клиента. -- Собственный RADIUS сервер, на транзитном узле, работает в проксирующем режиме, т.е. производит необходимые действия с запросом и отправляет его на parent RADIUS. Добавление/заполнение конкретных полей зависит только от логики взаимодействия с собственным биллингом/parent RADIUS-ом. В случае с FreeRADIUS-ом, нет никаких ограничений, всё добавляется/удаляется/заполняется как требуется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 24 ноября, 2010 · Жалоба Вы меня конечно извините, но вы вообще представляете место такого шлюза на сети оператора? Для меня эта железка - это аналог AS5350, через которую операторы стыкуют свою VoIP сеть с PSTN. Транзитной она называется из-за того, что не терминирует конечных абонентов. Не регистрируется на ней никто, то есть. Так кой ей функционал RADIUS Proxy? Ей, по сути, и Access-Request'ы слать смысла нет. Но это уже вопросы "не по окладу". Сказано красить в розовый, будем красить. ) Отсюда у меня и возникли вопросы к людям, которые эксплуатируют подобные железки. Интересует их мнение по данному вопросу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 24 ноября, 2010 · Жалоба Вы можете конкретно показать приходящие запросы от клиентов? И внятно объяснить что в них не устраивает? Т.е. примерно так: Auth Request Есть --> Должно быть Acc Request Есть --> Должно быть RADIUS-у по барабану, представляю ли я "место AS3550" в Вашей сети, у него RFC и только RFC. Ну и самое главное, КУДА запросы предполагается слать и в каком виде и что от Вас ждут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 24 ноября, 2010 · Жалоба Какие запросы? Вы о чём? INVITE/SETUP (VoIP/PSTN) в нашу сторону, INVITE/SETUP от нас. Всё. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 24 ноября, 2010 · Жалоба Какие запросы? Вы о чём?INVITE/SETUP (VoIP/PSTN) в нашу сторону, INVITE/SETUP от нас. Всё. Значит см. вариант 2. Транзитный узел должен сам формировать запросы к RADIUS серверу, на основе информации из REGISTER/INVITE/ACK/BYE/CANCEL. На каждый event - отдельный запрос, любой софтсвитч, за оч. редким исключением, так умеет. А вот логика формирования запросов определяется ожиданиями "той" стороны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
leveler Опубликовано 24 ноября, 2010 · Жалоба Вы мне честно признайтесь. Вы издеваетесь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Deac Опубликовано 24 ноября, 2010 · Жалоба Воспринимать собственное непонимание принципов взаимодействия клиент-серверной архитектуры RADIUS, как издевательство - весьма типично для людей не имевших дело с оной. Как Вам могли поручить то подобное, на что надеялись? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...