Процесс внедрения нового функционала всегда труден и тернист, а в случае с BRAS-авторизацией - особенно, так как требует настройки не только fastdpi/fastpcrf, но и Radius-сервера, на котором происходит основная работа по авторизации абонентов, и всего backend'а за Radius-сервером, - базы данных, биллинговой системы и пр. Здесь мы рассмотрим несколько подходов к внедрению авторизации.

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

Как описано ранее, авторизация проводится только по локальным IP-адресам. Локальность IP-адреса задается флагом local для автономной системы. Отсюда вывод - можно выделить диапазон тестовых IP-адресов, задать им номер автономной системы из диапазона зарезервированных для частных целей (64512..65534), и прописать, что эта автономная система локальная (local).

Таким образом, только IP-адреса, принадлежащие этой локальной автономной системе будут авторизовываться. "Живые" абоненты не будут затрагиваться до тех пор, пока автономные системы, к которым относится их IP-адреса, не будут объявлены как local. Это позволяет отлаживать авторизацию на боевом fastDPI.

Наконец, третья возможность, - объявить, что авторизацию нужно проводить только для указанных IP-адресов. Для этого в fastdpi.conf есть настройка auth_trace_ip, в которой можно задать один или два (но не более) IP-адреса:

auth_trace_ip=192.168.20.11,192.168.30.58

Указанные IP-адреса должны быть локальными (то есть относится к автономной системе, объявленной как local, см. выше). В случае наличия настройки auth_trace_ip авторизация будет проводится только для указанных в ней IP-адресов.

««« back to BRAS-авторизация