BiTel

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

Настраиваем связку BGBilling 6.0 (модуль Inet) и Cisco ISG (ISG пока тестовая, виртуальная, 7200 15.2(4)S6), для клиентов PPPoE.

Хотим реализовать функционал, при котором при ошибках в подключении, клиент все равно бы подключался и перенаправлялся на соответствующий web-портал. Собственно, этот функционал описан в документации (https://bgbilling.ru/v6.0/doc/ch17s13s03s01.html). Столкнулись с интересной проблемой, возможно, кто-либо уже сталкивался.

Наш конфиг на BG:
adius.disable.accessCodes=2,3,10,11,12
radius.disable.ipCategories=2
connection.start.fromAccept=1
radius.disable.attributes=cisco-avpair=subscriber:accounting-list=PPPOE-CLIENTS;cisco-avpair=subscriber:policy-directive=authenticate aaa list PPPOE-CLIENTS;cisco-SSG-Service-Info=QU;;1024000;;192000;;384000;;D;;1024000;;192000;;384000;;;cisco-avpair=ip:l4redirect=redirect list 199 to group PORTAL;

Сценарий первый: если в договоре поставить отрицательный баланс, то по идее, должно прилететь ошибка 12 (недостаточно средств) (коды ошибок - https://bgbilling.ru/v6.0/doc/ch17s20.html#accessCodes), однако у нас прилетает ошибка 10 (сервис заблокирован). При этом, подключении производится как задумано: вместо Access-Reject выдается Reject-To-Accept, клиенту выдается адрес из "ошибочного" блока, и производится редирект. Только непонятно, почему код ошибки неверный.

Сценарий второй: если юзер набирает неверный пароль, но BG просто выдает Access-Reject с кодом ошибки 2 (здесь все верно, значение "неправильный пароль"), однако подключения не происходит, адрес не выдается и соответственно, никакой редирект не работает.

Вот собственно, в этом и затык. Подскажите пожалуйста, может кто сталкивался? Спасибо.

Укажите в конфигурации
authorization.mode=1
Это режим работы авторизации по умолчанию для >=6.1

Может быть где-то что-то переопределено? Нужно лог смотреть.

У нас 6.0. Попробовал указать authorization.mode=1, но ситуация не изменилась:
Packet type: Access-Accept
Identifier: 2
Authenticator: {}
Attributes:
Reply-Message=10

Лог смотреть - хороший совет.

radius 09-27/15:02:10 INFO [rdsLstnr-p-8-t-10] InetNas - Search by username=cisco3
radius 09-27/15:02:10 INFO [rdsLstnr-p-8-t-10] InetRadiusProcessor - [username=cisco3] Login password error.
radius 09-27/15:02:10 INFO [rdsLstnr-p-8-t-10] InetRadiusProcessor - Return code=2
radius 09-27/15:02:10 INFO [rdsLstnr-p-8-t-10] InetRadiusProcessor - RESPONSE_BEFORE_POSTPROCESS:
Packet type: Access-Reject
Identifier: 3
Authenticator: {}
Attributes:
Reply-Message=2

Process time auth: 9

radius 09-27/15:02:10 INFO [rdsLstnr-p-8-t-10] InetRadiusListenerWorker - RESPONSE:
Packet type: Access-Reject
Identifier: 3
Authenticator: {CA A9 61 39 A8 4B 6F C5 A3 68 9D 86 CD 87 60 56}
Attributes:
Reply-Message=2

Но, собственно, это не проливает свет на то, почему не отрабатывает поведение при ошибках.

Требуется перезапуск InetAccess и InetAccounting.

А при перезагрузке конфига NAS'а там в логах точно
radius.disable.accessCodes=2,3,10,11,12
?

Amir, подскажите пожалуйста, как перезагрузить конфиг NAS и в каком логе посмотреть?

В radius-processor.log есть строчки:
radius.disable.accessCodes=2,3,10,11,12

После перезапуска InetAccess и InetAccounting код ошибки пришел верный:

09-27/16:20:37 INFO [rdsLstnr-p-8-t-2] InetRadiusListenerWorker - RESPONSE:
Packet type: Access-Accept
Identifier: 5
Authenticator: {63 9C 9A 91 A9 A8 0C D8 E6 5A 15 EF 46 21 CF 55}
Attributes:
Reply-Message=12

Но вопрос с кодом 2 остается открытым:
09-27/16:26:13 INFO [rdsLstnr-p-8-t-3] InetRadiusListenerWorker - RESPONSE:
Packet type: Access-Reject
Identifier: 6
Authenticator: {B5 75 26 3B 26 A0 1A 4F 11 52 31 BD D2 95 68 5A}
Attributes:
Reply-Message=2

Там действительно для ошибки пароля не работало. В ближайшие дни выложим обновление.

Спасибо, ждем!

Выложили. Не забудьте сделать бэкап старых библиотек.