freeradius 3

[tom]

Вітаю, хто може підказати. Ось частина коду з radreply де авторизується невідомий клієнт
IF usr_id IS NULL OR usr_id=0 THEN
            UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
            UPDATE mac_uid SET mac=NULL WHERE mac=usr_mac AND oneconnect>0;
            START TRANSACTION;
            SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p
                WHERE uid=0 AND type='dynamic'
                    AND tags LIKE CONCAT('%,', tag, ',%')
                    AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
                ORDER BY RAND() LIMIT 1 FOR UPDATE;
            INSERT INTO mac_uid VALUES(
                NULL, usr_mac, INET_ATON(usr_ip), 0, UNIX_TIMESTAMP(), dev_mac, port, 2)
            ON DUPLICATE KEY
                UPDATE ip=IF(ip>0 AND device_mac=dev_mac AND device_port=port, ip, INET_ATON(usr_ip)),
                    uid=0, device_mac=dev_mac, device_port=port, oneconnect=2, time=UNIX_TIMESTAMP();
            COMMIT;
            SELECT INET_NTOA(ip) INTO usr_ip FROM mac_uid
                WHERE mac=usr_mac AND device_mac=dev_mac AND device_port=port;
       ELSE


Я так розумію призначеня цих рядків
            UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
            UPDATE mac_uid SET mac=NULL WHERE mac=usr_mac AND oneconnect>0;
переписати всим невідомим клієнта ір=0 які оновлювали данні більше ніж 3600с, тобто скоріш за все не активним клієнтам. Та обнуляєм мак, попереднім записами в таблиці з таким же маком, і коли один на порту.

Тепер питання, невідомий клієнт довгийчас не авторизується і вже вдруге чи втретє проходить авторизацію. Оськільки кожного разу його відправляє в цю частину коду то плодяться записи типу
+-------+--------------+-----------+-----+------------+------------+-------------+------------+
| id    | mac          | ip        | uid | time       | device_mac | device_port | oneconnect |
+-------+--------------+-----------+-----+------------+------------+-------------+------------+
| 22242 | NULL         | 168362220 |   0 | 1533109938 | 735        |           2 |          2 |
| 22244 | 64d154751691 | 168393556 |   0 | 1533113804 | 735        |           2 |          2 |
+-------+--------------+-----------+-----+------------+------------+-------------+------------+
Які після привязки клієнт до учотки, можуть викликати трудності.

Питання, чи варто переживати за це, чи хай ці дублі живуть і їх періодично чистити?
 

[tom]

Питання два.
Ситуація accel-radius-bill
йде аккаунтінг, все гуд. По якимось причинам пропадає звязок з радіусом у нас більше часу аккаунтінга в білінгу і він вважає клієнта не авторизованим. Відновився звязок і accel продовжує слати аккаунтінг. Питання - як на це відреагує білінг?

[Efendy]

Для динамических адресов отреагирует плохо. Но час отсутсвия инета - это уже чп и такое бывает крайне редко. Можно мониторить такие ситуации и раз в год и при ее возникновении отребутать сервер или сервис

[tom]

Ну в сезон гроз це ЧП стає досить частим випадком.

[Efendy]

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

[tom]

Потреби мереж може й бути різні, але способів авторизації не так вже й багато. Можливо варто зробити різні гілки? Хоча, це впринципі залежить від бачення і бажання розробника. Я мабуть не прошу переробити, просто хочу розібратися і зрозуміти чому відбуваються деякі процеси, що впливають на роботу системи. І відповідно відреагувати - а) змінити систему б) змінити взаємодію з білінгом. Навіть ті радіус процедури, під ірое прийшлось збирати з різних джерел по частинам і тулити вкучу.

А по віджеранню памяті модулем СОА, так і не можу його подолати ((

[Efendy]

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

[tom]

Сесія підніметься після чергового дхцп запиту

[tom]

Для динамических адресов отреагирует плохо. Но час отсутсвия инета - это уже чп и такое бывает крайне редко. Можно мониторить такие ситуации и раз в год и при ее возникновении отребутать сервер или сервис

Ось приклади ЧП
Були проблеми з БД (можливо ще залишилися), лочилась база і не оновлювалося поле release. Відповідно полізли дублі, для відновлення тре бутати весь сервак, а так би при відновленні - по аккаунтінгу відновився би релізтайм.

[Efendy]

Покопался я в очередной раз с FreeRadius-ом версии 3 - голова болит, протрахался хз сколько часов, даже в исходники лез. И вот какие замечания:

1) Хочу сначала отметить, что в конфиге Cell-а авторизация принимается всегда, даже если неправильный пароль. У него такая схема, но я думаю большинству это не подходит. Я нашел причину, почему не получилось проверить пароль - новый радиус в ответе процедуры radcheck требует :=, а не ==

2) В процедуре атрибут Password меняется на Cleartext-Password - это уже упоминалось, просто отмечу еще раз

3) Обнаружилось идиотское поведение freeradius3: он делает radcheck, затем radreply и потом проверяет пароль. Никуда не годится проверять пароль после того, как для учетки будет запрошен динамический ip, а в итоге выдан чужаку не будет. Поэтому пришлось проверять пароль и в radreply (добавлен параметр "пароль" - слава богу, он есть в параметрах радиуса)

4) Чтобы mpd5 получил корректные ответы радиуса на эккаунтинг нужно чтобы radupdate заапдейтило как минимум одну строку в базе. Лол. Мы делаем тупой запрос: UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1, который по сути ничего не делает, но без него mpd5 будет постоянно рвать сессии.

5) Чтобы в accounting секции шло разделение на start и stop запросы - нужно вставить строку:
        reference = "%{tolower:type.%{Acct-Status-Type}.query}"

6) По ходу выяснилось, что mpd уже (ура) может принимать кое-какие атрибуты в аккаунтинге. Теперь можно, например скорость менять (для NoDeny это не нужно, он фаерволом режет) прямо на ходу. Но главное мы можем кильнуть юзера без COA. Зачем килять? А например, если мы видим, что юзеру поменяли ip. Тогда он переконнектится и получит новый. Собственно из-за этой проблемы смены ip и была немного долюанутая схема, что в radupdate NoDeny игнорит ip от радиуса и вычисляет свой. Теперь все будет проще и надежней

7) Я голову сломал, но так и не понял как можно в радиусе через sql модуль передать атрибуты из radreply (думаю никак). Поэтому в самом конфиге делаю проверку if( %{sql: проверяем привязан ли еще ip к юзеру}) { дропаем сессию }. Для дропа сессии надо атрибуты в словарь радиуса добавить (в доке отразил это)

8 ) Заюзал radstop чтоб авторизация удалялась сразу после дисконнекта, а не по таймауту как раньше (сделано было из-за того, что в этом случае не велся лог авторизаций). Сразу удалять авторизации нужно для того чтобы контролить параллельные сессии (не давать двум юзерам сидеть под одним логином). Кстати я уже получил более-менее рабочий вариант, но надо еще тестить. Да и radstop под конец изменилась и у меня уже нет сил ее тестить (возможно в доке не рабочая), завтра.


Дока

[goletsa]

1,2 - Помню сталкивался. Про принудительное прохождение авторизации в любом случае - некоторые биллиги так делают, потом пихая клиентов в отдельный пул для неизвестных. Тогда имеет смысл пускать всех, а потом сортировать по пулам.

3) Обнаружилось идиотское поведение freeradius3

Разве это особенность именно 3 версии? Вроде сталкивался с этим раньше еще и думал что это нормальное поведение.
То есть если клиент даже не прошел авторизацию то все равно reply отрабатывал.
Но у меня статические адреса, динамики нет от слова совсем потому не критично если ответ будет. Причем я логирую в этом месте попытки конектов в базу. Правда как пароль сверять, он разве открытым текстом приходит?

[elite]

Ось приклади ЧП
Були проблеми з БД (можливо ще залишилися), лочилась база і не оновлювалося поле release. Відповідно полізли дублі, для відновлення тре бутати весь сервак, а так би при відновленні - по аккаунтінгу відновився би релізтайм.

А разве не должен Accel-ppp дропать сессии при отсутствии ответа аккаутинга от радиуса продолжительное время?

[Efendy]

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

Да.

Кстати допилял я. Сейчас с нуля ставлю и перепроверяю. Добавил еще одну фичу: Блокирование одновременного подключения нескольких абонентов с одним логином. Самое прикольное как она включается (процедуры не надо менять!): Вам необходимо в /usr/local/etc/raddb/mods-enabled/sql в конце строки authorize_check_query заменить ноль на единицу.

[FlySky11]

Покопался я в очередной раз с FreeRadius-ом версии 3 - голова болит, протрахался хз сколько часов, даже в исходники лез. И вот какие замечания:

Стас, добавь в доку, с моей статти ошибку и устранение по радиусу будет полезно знать
    

Код:

FreeBSD + FreeRadius 3 + проблема установки с портов

И кое что добавлю от себя

В строчке процедури radcheck:

Код:

  SELECT id,name,'Cleartext-Password' AS Attribute,AES_DECRYPT(passwd,'htpew7') AS Value,':=' 

Пароль (passwd,'htpew7') должен быть одинаковым, как в файле /usr/local/nodeny/sat.cfg

При создании процедур смотрите внимательно!!!!)
В доке  там hardpass

Код:

    SELECT id, name, 'Cleartext-Password' AS Attribute, AES_DECRYPT(passwd, 'hardpass') AS Value,':=' 

А в стоковом файле sat.cfg там  htpew7

[Efendy]

ок