UTM5+freeradius

Submitted by dragomir on Fri, 10/08/2010 - 22:29

добавляем в sql.conf
запросы в базу UTM5 для авторизации

freeradius авторизация из файла

Submitted by dragomir on Wed, 12/07/2011 - 23:21

сразу опишу задачу.
Есть биллинг UTM5 который дружит с freeradius и авторизация идет из базы UTM5 и ip-адрес каждому клиенту привязан свой в билллинге жестко из подсети 176.16.0.0/16.
У заблокированных клиентов авторизация не проходит.
Задача состоит в том, чтоб заблокированные клиенты авторизовывались, но им выдавались ip-адреса из другого пула, в нашем случае я выбрал 172.16.0.0/22
Реализовать решил через файл со связками логин/пароль. Если клиент заблокирован в базе UTM5 радиус лезет в файл users, авторизовывает клиента и выдает ему адрес из нового пула.
теперь конфиги:

UTM5 + freeradius (2 dynamic ip pool) + urfaclient на php + pppoe-server (linux)

Submitted by dragomir on Fri, 03/23/2012 - 18:47

Имеем мы биллинг UTM5.
Решили отказаться от NATа и раздать клиентам реальные динамические ip-шники.
Порыскав на форуме netup.ru, я не нашел ничего, что удовлетворяло бы моим запросам.
NASы у нас в виде машин на Линухе, freeradius, urfaclient на php написали умельцы с форума. Единственное, что нашел по теме, и за это огромное человеческое спасибо wingman'у с форума, который осветил эту тему более ярко:
http://www.netup.ru/phpbb/viewtopic.php?t=7948&highlight=%E4%E8%ED%E0%EC...

No available ip addresses in pool.

Submitted by dragomir on Thu, 11/28/2013 - 01:32

Всё началось с UTM5 + freeradius (2 dynamic ip pool) + urfaclient на php + pppoe-server (linux) - See more at:
http://www.linuxsnippets.net/ru/node/227

Прошло пару лет и вот я наткнулся на один баг.
У меня пользователи pppoe начали получать виртуальные ip-адреса из подсетей 10.67.15.0/24 и 10.67.16.0/24.
При чем начали получать не все, а только некоторые и в основном с одного только NAS-а.
Это служебные пулы pppoe-сервера по умолчанию. Если радиус не назначил пользователю ip-адрес то ему по умолчанию назначает pppoe-server.

Redback Ericsson + Freeradius log

Submitted by dragomir on Tue, 04/17/2018 - 20:21

Всё началось с того, что Эриксон работая как брас с pppoe слал в атрибуте Calling-Station-Id значения типа Redback#1/4#185:112, а не mac-address клиента
Такая ситуация совсем не устраивала саппортов, когда нужно было провести диагностику.
Вобщем ближе к делу, логи радиуса были такие:

Login OK: [simaginev/<CHAP-Password>] (from client se1200 port 335556290 cli Redback#1/4#136:101)

А мне хотелось видеть mac клиента.