8.4.6. Reject-To-Accept

Замечание

Вы можете пропустть этот раздел при первичной настройке системы.

Иногда в случае неудачной авторизации нужно все равно разрешить установку сессии, но с определенными атрибутами. Например, если у клиента нет денег на счету, но соединение все равно нужно установить, чтобы пустить его к серверу статистики. Для настройки режима Reject-To-Accept в конфигурацию модуля добавьте:

reject_to_accept.<коды ошибок>=<передаваемые атрибуты>
reject_to_accept.nas=<коды nas-ов>
reject_to_accept.db.write=0

Коды ошибок авторизации доступны здесь. В случае возникновения ошибок авторизации с кодами, указанными в этой конфигурации, происходит выдача accept - пакета. Клиенту выдается адрес из пула адресов стандартным образом (в списке передаваемых атрибутов должен быть Framed-Pool=<имя пула>). Так же можно указать коды NASов, для которых производится данная подмена ответа Radius. Если это параметр не указан, то обработка производится для всех NASов.

Пример:

reject_to_accept.2,3=Session-Timeout=100;cisco-Fax-MDN-Address=1;Framed-Pool=fake_pool
reject_to_accept.4,11=Session-Timeout=200;Framed-Pool=fake_pool_2
reject_to_accept.nas=10,15

При указании параметра reject_to_accept.db.write=1 ошибки заносятся в таблицу БД dialup_reject_to_accept_<mid> для возможности перенаправления пользователя на страницу с описанием ошибки. Страница доступна по адресу: http://<ip>:<port>/bgbilling/pubexecuter?module=dialup&action=RejectToAccept&mid=<mid>, где:

<ip> - адрес сервера биллинга;
<port> - порт сервера биллинга;
<mid> - код экземпляра модуля.

При получении запроса на данную страницу пользователю генерируется HTML страница с использованием шаблона dialup_reject_to_accept_<mid>.xsl, где <mid> - код экземпляра модуля. В качестве образца поставка модуля включает шаблон dialup_reject_to_accept.xsl, который должен быть скорректирован соответсвующим образом и переименован к нужному виду. Идентификация пользователя производится по IP-адресу, с которого был произведен запрос. IP-адрес может быть передан в HTTP-заголовке, указанном в параметре header.name.remote.addr конфигурации сервера биллинга, например X-Real-IP.

Обычная схема перенаправления пользователя на страницу с ошибкой выглядит следующим образом:

  1. пользователю выдается IP-адрес из определенной сети для Reject-To-Accept соединений;

  2. маршрутизация настроена таким образом, что все обращения из данной сети перенаправляются на проксирующий HTTP-сервер, например nginx;

  3. проксирующий HTTP-сервер получает все запросы на определенном порту и проксирует их на указанный выше URL, подставляя адрес, с которого было обращение, в заголовок HTTP-запроса;

  4. сервер биллинга получает запрос на данный URL и по IP-адресу определяет пользователя, генерируя ему персональную страницу с ошибкой.

При разработке собственного XSLT-шаблона использовать следующую методику:

  1. настроить режим reject-to-accept с записью ошибок в БД, добиться создания таблицы dialup_reject_to_accept_<mid> и внесения в нее записей;

  2. изменить в таблцие dialup_reject_to_accept_<mid> какую-либо из записей с тем, чтобы поле ip было равно IP-адресу вашей машины;

  3. обратиться по URL: http://<ip>:<port>/bgbilling/pubexecuter?module=dialup&action=RejectToAccept&mid=<mid>&contentType=xml при этом страница собирается в браузере клиента, XSLT-шаблон запрашивается браузером по пути, указанному в параметре web.xslt конфигурации сервера биллинга;

  4. просмотреть исходный код страницы для просмотра XML дерева, доступного из XSLT шаблона.

Замечание

Таблица dialup_reject_to_accept_<mid> может храниться в "мусорной" базе. Для ускорения работы для данной таблицы используется тип таблиц Memory, хранимых в памяти. Для корректной работы режима перенаправления на страницу с ошибкой в списке RADIUS-атрибутов, передаваемых в accept пакете, должны обязательно быть Framed-Ip-Address и Session-Timeout, в противном случае запись в таблицу произведена не будет.