Процесс внедрения нового функционала всегда труден и тернист, а в случае с 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-адресов.