[lidia]

Один из наших клиентов задал нам одну интересную задачку:

При проведении плановых работ или возникновении аварийной ситуации на сервере с Radius требуется обеспечить доступ абонента к услуге Интернет и всё это без необходимости перенастройки сетевого оборудования.

 

Этот вопрос для операторов связи приобретает все большую актуальность в связи в возрастающей конкуренцией и борьбой за абонента. Один/два раза клиент не сможет воспользоваться услугой, он сразу уходит к конкуренту.

 

Первой мыслью была установка программного балансировщика. В случае выхода из строя мастер-radius балансировщик бы переключал нагрузку на резервный радиус. Но готового условно бесплатного продукта мы не нашли, да и согласовать со службой ИБ было бы сложно, как и обосновать закупку нового коммерческого продукта.

 

Поэтому было принято решение написать новый модуль (а-ля bypass), который бы:

- проводил безусловную авторизацию всех абонентов (на все запросы Access-Request отвечал бы Access-Accept)

- выдавал универсальный профиль на все сессии абонентов

- отправлял подтверждения на radius-accounting

- мог бы работать на том же ip адресе и порту, что и основной radius агент (работа непосредственно с фреймами Ethernet на канальном уровне)

- работал без использования СУБД

- имел минимальные требования по ресурсам сервера

При этом, нам важно было оставить возможность проведения диагностики работы основного radius при возникновении аварийной ситуации (пакеты бы получались, обрабатывались, но ответы бы не отправлялись на BRASы)

 

Модуль уже готов, протестирован и на днях модуль будет запущена эксплуатация в реальных условиях у клиента.

 

Если модуль заинтересует, мы, конечно же, поделимся и скоро его анонсируем официально.

 

 

Тем не менее, хочется узнать у сообщества, а как вы решаете подобную задачу предоставления бесперебойного доступа к Интернет?

Edited August 24, 2016 by lidia

[wildmoon]

А модуль чего это? Какого то существующего биллинга? Или что то отдельное

[myth]

accel-ppp и без подтверждений работать умеет. С авторизацией засада, да. Без правки конфига не решается. Но можно накостылить что-нибудь.

Edited August 24, 2016 by myth

[lidia]

А модуль чего это? Какого то существующего биллинга? Или что то отдельное

 

Модуль в данном контексте - это синоним сервиса, отдельного бинарника.

Этот сервис умеет работать как с радиусом нашего биллинга (слушает ip/порт тот же, что и радиус), так и независимо/автономно.

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

Edited August 24, 2016 by lidia

[MATPOC]

Один из наших клиентов задал нам одну интересную задачку:

При проведении плановых работ или возникновении аварийной ситуации на сервере с Radius требуется обеспечить доступ абонента к услуге Интернет и всё это без необходимости перенастройки сетевого оборудования.

Поэтому было принято решение написать новый модуль (а-ля bypass), который бы:

- проводил безусловную авторизацию всех абонентов (на все запросы Access-Request отвечал бы Access-Accept)

- выдавал универсальный профиль на все сессии абонентов

- отправлял подтверждения на radius-accounting

- мог бы работать на том же ip адресе и порту, что и основной radius агент (работа непосредственно с фреймами Ethernet на канальном уровне)

- работал без использования СУБД

- имел минимальные требования по ресурсам сервера

Я в своё время для freeradius решил задачу гораздо проще - на время проведения работ в файле users прописал секцию DEFAULT:

 

DEFAULT NAS-IP-Address == 10.0.0.1, Auth-Type = Accept
   	Cisco-AVPair = .....
   	Cisco-AVPair += .....
   	Fall-Through = No

 

Можно ещё проще, без указания NAS-IP-Address, если этот радиус обслуживает только IP доступ..Но у меня и авторизация и аккаунтинг на одном сервере. В биллинг потом загружал простеньким скриптом, который парсил detail лог.

[infery]

Гораздо проще не использовать радиус. ИМХО. На тазиках есть ratelimit, на микротах - queue. С железными брасами (asr,se и тп) правда хз как. Сами используем СКАТ в роли браса, очень удобно

[s.lobanov]

Смешно, что хочется плакать. Ну почему, объясните почему, девелоперы российских биллингов постоянно изобретают свои проприетарные костыли. Как же вы з*****и своей своими гнилыми поделками.

 

Как и написали выше, задача решается за тривиальным конфигом freeradius с помощью юзера DEFAULT, который отдаёт всем юзерам access-accept+нужные аттрибуты. И на аккаунтинг отвечает что принимает его.

 

На самом деле, задача становится интереснее, когда абонентам раздаются белые IP, несколько брасов и выделение IP-адресов делается через радиус. Хз можно ли это сделать через freeradius DEFAULT. Если можно, то отлично. Если нельзя, то это пожалуй единственный кейс когда нужно что-то девелопить под безусловную авторизацию. Но с учётом того, что щас у многих NAT и можно не возиться с распределением пула из radius, то возвращаемся к freeradius DEFAULT.

[saaremaa]

Ну почему, объясните почему, девелоперы российских биллингов постоянно изобретают свои проприетарные костыли.

...потому что кушать хотят, а мы с вами потом мучайся.

[taf_321]

Какое-то кондовое велосипедостроение. Кто мешает перед проведением работ просто сгенерить users файл со всеми логинами-паролями-нужными-адрибутами-адресами? И на момент профилактики просто перевести NAS'ы на этот резервный радиус сервер (только не говорите, что еще остались такие NAS'ы, которые не умеют в несколько радиус-серверов, либо не могущих переключаться с одного на другой налету)?

 

Накрутить от же FreeRADIUS это дело 15 минут скрипторисования. В случае некоторых вендоров (кубокилометр диабаза в огород Netup'а) подменный радиус при работе оказывается в разы лучше "родного" недоразумения.

[orlik]

Странное решение , у нас просто при потери связи с базой радиус всегда возвращает шаблон , в котором прописан тарифный план и всегда ACCESS-ACCEPT

[vitalvas]

На самом деле не нужно делать каких-либо таких прослоек. От них в основном геморой.

Для проведение тех работ хватает максимум 1 час. За это время можно не подключать абонов.

 

На брасах, как правило, не ограничено количеством радиус серверов. Что Вам мешает поднять на резервной площадке радиус сервер с базой?...

Есть нюанс с Stop пакетами. Этот нюанс можно спокойно обойти с помощью очереди. Как система заработает - все данные доедут.

 

У меня тоже есть такой костыль. Перед тем как уходить в оффлайн - можно выгрузить в xml-ку все нужные данные. Даже под подобные задачи написал свой радиус сервер, где могу крутить логикой работы как захочу.

Знаете сколько раз пригодилось такое решения за 5 лет? Целых 3 раза. 2 с которых - падения канала связи в ДЦ.

 

Все это тупо не нужно. FreeRadius прекрасно умеет делать балансировку как и по бекендам так и по другим радиус серверам. И докрутить туда кеш или другую гадость не составляет труда.

Если Вы начали велосипедостроение без предварительного изучения вопроса - Вы тупо потратили время на систему, которая в принципе и за бесплатно никому не нужна. Все можно реализовать довольно просто. Тем более инструментов для этого предостаточно.

[FATHER_FBI]

Какое-то странное задание у ТС.

Его можно решить при связке FreeRADIUS+SQL, но ТС не хочет что бы была база данных.

[Ivan_83]

Фрирадиус это такая не очевидная софтина в плане конфига, что кажется что её писали инопланетяне :)

Подозреваю что в качестве тупого балансира с резервированием сейчас можно уже даже нгинх юзать, туда натащили кучу всякой непрофильной гадости.

[vitalvas]

Фрирадиус это такая не очевидная софтина в плане конфига, что кажется что её писали инопланетяне :)

С версиями эта софтина превратилась с AAA сервера в AAA фреймворк.

 

Подозреваю что в качестве тупого балансира с резервированием сейчас можно уже даже нгинх юзать, туда натащили кучу всякой непрофильной гадости.

Можно, но зачем?...

FreeRadius прекрасно баланирует.

 

Я ждал когда наконец-то nginx научится балансировать tcp/udp трафик. Разработка модулей для "phantom i/o engine" приносит еще то удовольствие.

[Ivan_83]

Можно, но зачем?

Для тех кто не осилил инопланетную логику создателей фрирадиуса и их unlang :)

Я вот довольно много и долго возился с ним, явно больше месяца, много чего там накофигурял и понаписал. прошло 4 года и я уже не помню как оно работает и как конфигурять. Притом что с во многие конфиги других софтин лазаю тоже не часто но там всё ощутимо понятнее.

[orlik]

Ну и , не скажу за всех вендоров , но cisco и juniper обычно разрешают несколько типов авторизации, что-то в роде

aaa ppp authentication default radius none

т.е. если помрет радиус , отключить авторизацию и подключать всех просто так ...

[[anp/hsw]]

Рекомендую в случае аварии раздавать адреса из специально зарезервированой для такого случая подсети (серой или белий - не важно).

При дохлом основном радиусе вы не знаете, какие абоненты еще работают, а какие нет, следовательно, не сможете обеспечить (на уровне radius) отсутствие коллизий адресов.

Можно, конечно, достать информацию о занятых адресах из таблицы маршрутов, но это лишний геморрой, и еще один отвлекающий момент при проведении плановых работ.

 

aaa ppp authentication default radius none

т.е. если помрет радиус , отключить авторизацию и подключать всех просто так ...

Тут остается открытым вопрос о синхронизации адресной базы при более, чем одном брасе (надо выдавать в каждом из отдельной подсети для подстраховки).

 

Либо поднимается на любой тачке freeradius с простым конфигом типа такого:

 

home_server_pool mainpool {
       type = fail-over

       home_server = remote_radius
       fallback = local_radius
}

realm DEFAULT {
       pool = mainpool
}

realm NULL {
       pool = mainpool
}

[Diamont]

Можно ли как то через вайршарк или иным способом выцепить из NASа shared secret? Есть доступ к радиусу и возможность снифать канал между насом и радиусом. На самом радиусе секрет не верный, поэтому он шлёт режекты. Либо заставить слать аксепты даже с неправильным секретом и логином/паролем.

[orlik]

Можно ли как то через вайршарк или иным способом выцепить из NASа shared secret? Есть доступ к радиусу и возможность снифать канал между насом и радиусом. На самом радиусе секрет не верный, поэтому он шлёт режекты. Либо заставить слать аксепты даже с неправильным секретом и логином/паролем.

А смысл в таком радиусе если он все равно шлет режекты ? Прописывайте на оборудовании одинаковый и все будет.

 

Обычно проще с насов вытащить пароль, он там толком не зашифрован

[OK-2004]

Если бы я был Saab95, то я бы сказал , что если pptp/pppoe/l2tp сервер сделан на микротик - то при "задизабленных" ppp/secrets микротик пользуется радиусом, если их "заенаблить" - то в начале микротик ищет login-password в них а потом обращается по радиусу в случае ненахождения.

[myth]

orlik, что, и ссх нет, чтоб правильный вбить? Оборудование вообще ваше?

[Diamont]

А смысл в таком радиусе если он все равно шлет режекты ? Прописывайте на оборудовании одинаковый и все будет.

 

Обычно проще с насов вытащить пароль, он там толком не зашифрован

Смысл в том чтобы дать пользователю доступ. Прописать нельзя. Можно только менять пароль и следить за запросами/ответами наса/радиуса. К радиусу доступ полный так что если заставить его аксептить игноря секрет, было бы хорошо. Сейчас режектит так как верный пароль шифруется насом и на выходе уже не совпадает с плейн текст паролем в радиусе. Я так понимаю, выход это пересобрать фрарадиус либо написать свой радиус? Или даже в этом случае не получится обмануть нас?

Всё оборудование разумеется лежит на столе.

[orlik]

Так если все оборудование на столе , и есть доступ к NAS , выдерните из его конфига пароль и пропишите его на radius.

 

Пересобрать радиус наверное можно , вопрос в другом , вы не сможете проверить клиентский пароль , правильный он или нет

[Diamont]

Задача не в проверке конкретного пароля а в том, чтобы дать доступ клиенту. Клиент вводит имя user и пароль pass. В радиусе вбито тоже самое. Но получает режект потому что секрет не верный. Это можно обойти? Либо подобрать (сбрутить) секрет какой нибудь софтиной на основе запросов НАСа.

Доступ к нас есть, но не полный, в том и загвоздка. Секрет не узнать. И такое с десятками насов. На стол поставили лишь один для эксперементов.

[infery]

Доступ к нас есть, но не полный, в том и загвоздка

если это linux, должна быть возможность загрузиться в single user. Да в конце концов жесткий диск смонтировать в другой комп.