/ Flickr / Alexxx Malev / CC
Развитие функций NAT и IPFIX
В новой версии продукта была добавлена возможность подключать NAT для пользователей, одновременно использующих «белые» и «серые» адреса. Для этого на одном логине объединяются несколько IP-адресов, а затем на него назначаются политики и подключаются услуги. Эта функция удобна для корпоративных клиентов, которые покупают у оператора блоки адресов.
Вот пример команды для объединения адресов в один логин:
fdpi_ctrl load –bind_multi –user имя_абонента: ip_адрес_или_блок
При этом хотелось бы отметить, что функция CG-NAT требует включения в схему резервного устройства. Это связано с тем, что при установке системы СКАТ «в разрыв» bypass-карты не помогают, поэтому выход платформы из строя прекращает выдачу адресов. Таким образом, рекомендуемая схема включения выглядит так:
Схема установки СКАТ с функцией CGNAT (Источник: вебинар)
Что касается протокола IPFIX, то он позволяет передавать аналитические данные со СКАТ как на внутреннюю СХД сервера, так и на внешние агрегаторы. В своем новом воплощении IPFIX получил две новые функции. Первая — экспорт признака блокировки ресурса: скажем, если ресурс оказался заблокирован по черным спискам, то в поле LOCKED появится соответствующее значение. Вторая — экспорт имени хоста для протоколов HTTPS и QUIC.
Развитие IPFIX (Источник: вебинар)
Отметим, что одним из наиболее популярных способов анализа информации с платформы DPI является связка демона-коллектора nfcapd, дампа nfdump и визуализатора NfSen, являющегося графическим интерфейсом для данных nfdump. Для сбора информации в формате IPFIX подойдет любой универсальный IPFIX-коллектор, который понимает шаблоны, или утилита IPFIX Receiver. После накопления данных хотя бы за одни сутки NfSen строит графики по протоколам, объему трафика и др.
Помимо графиков, с помощью NfSen можно строить отчеты за произвольные периоды по протоколам и направлениям. При этом нам хотелось бы отметить, что визуализатор не рекомендуется устанавливать на сервер, где развернуто решение DPI, – подготовка отчетов сильно загружает центральный процессор, а это может отрицательно сказаться на производительности DPI-платформы.
Набор функций для работы в качестве L3 BRAS
Сервисный шлюз BRAS — это новая функция системы контроля и анализа трафика СКАТ. Частично её возможности были представлены еще в СКАТ 5.0. В новой версии появилась авторизация сессий IPoE на radius, что расширило спектр возможностей оператора связи в сфере контроля доступа абонентов к интернету, а также при работе с дополнительными тарифными опциями (работа L3 и идентификация клиентов по IP или метке Q-in-Q).
Отметим, что СКАТ с функцией BRAS внедряется в сети оператора «в разрыв», однако с использованием дополнительных компонентов: СКАТ PCRF, radius-сервера и биллинг-сервера. О том, как выполняется конфигурирование функции L3 BRAS читайте в одном из наших материалов, который вы найдете по ссылке.
Место СКАТ L3 BRAS в сети оператора (Источник: вебинар)
У системы СКАТ с функцией BRAS есть несколько применений, среди которых стоит выделить управление доступом абонента при нулевом балансе, чтобы пользователь имел возможность перейти на страницу платежной системы и пополнить счет, управление общей полосой канала (тарифные планы, QoS), а также идентификацию абонентов в Wi-Fi-сети (например по телефонному номеру).
Что касается последнего пункта, то работа по идентификации пользователя происходит на оборудовании оператора связи. Для этого оператор должен иметь стандартный набор устройств (коммутаторы, маршрутизаторы и т. д.), а также систему DPI, DHCP-сервер для организации выдачи адресов абонентам, ВМ с веб-сервером Apache и NAT с записью лога трансляций.
Доступ к интернету через точку общего доступа
Работает система следующим образом. Устройство абонента подключается к Wi-Fi-роутеру, который, в свою очередь, «просит» новый IP у DHCP-сервера. Последний передает данные обратно роутеру и вызывает shell-скрипт, который активирует в СКАТ DPI тариф с ограничениями доступа.
Далее, когда пользователь вводит нужный ему URL, веб-сервер получает запрос на страницу идентификации, где пользователь вводит номер телефона, за которым следует отправка запроса на код доступа. Сервер генерирует случайную последовательность цифр и отправляет её пользователю по СМС. Когда код подтвержден, новый shell-скрипт устанавливает тариф доступа Wi-Fi и переадресует клиента на запрошенный URL.
Для реализации вышеописанной схемы необходимо настроить оборудование оператора: систему DPI, DHCP-сервер, веб-сервер. Инструкции по настройке вы можете найти в одном из наших материалов.
Поддержка работы с сервером управления политиками PCRF
Сервер PCRF может располагаться на отдельном устройстве и руководить множеством PCEF либо являться частью системы DPI СКАТ. Сервис fdpi_pcrf выполняет роль BRAS для fastdpi — для исходящего клиентского трафика fdpi_pcrf запрашивает авторизацию у radius-сервера, профиль тарифного плана и список предоставляемых услуг. Чтобы обеспечить отказоустойчивость системы, есть возможность реализовать схему резервирования master-slave.
Работа сервера управления политиками (Источник: вебинар)
Сам сервер fdpi_pcrf интегрирован с fastdpi и имеет три компонента. Первый — модуль авторизации в fastdpi, который анализирует исходящий трафик от локальных клиентов. В случае отсутствия авторизации клиента, модуль отсылает TCP-запрос на fdpi_pcrf. Второй — сервер fdpi_pcrf, который принимает по внутреннему протоколу запросы на авторизацию от fastdpi и обрабатывает их. Ну и третий — это управляющий модуль fastdpi, принимающий результаты работы fdpi_pcrf по протоколу fdpi_ctrl и пишущий их в базу данных клиентов.
Подробнее о системе СКАТ DPI 6.0 «Севастополь» вы можете узнать из нашей презентации, представленной выше. Часть видео посвящена секции Q&A — вопросы задавали участники вебинара в режиме онлайн.
P.S. Другие материалы из нашего блога:
Комментарии (6)
RicoX
14.02.2017 17:55Подскажите где посмотреть список поддерживаемых атрибутов радиуса. Интересует в частности работа с динамическими пулами и шейпер/полисер через атрибуты радиус, в ссылке на документацию все ну очень кратко.
VASExperts
15.02.2017 15:36Спасибо за интерес! Ответили в личных сообщениях.
И ссылка на развернутое описание.RicoX
16.02.2017 09:29+1Спасибо, пожалуй основное замечание — это использование собственного вендор-ид, так как многие билинги имеют свой личный радиус сервер (не фрирадиус), где забиты стандартные вендоры с их ид: циски, джуны, редбеки и т.п. Вписать же нового вендора часто не тривиальная задача, было-бы неплохо предусмотреть опцию конфига, который бы заставлял работать радиус в режиме совместимости атрибутов с цисковскими (как самые распространенные) — это упростит многим желающим интеграцию с уже существующими окружением.
khizmax
17.02.2017 18:26Спасибо за ценный совет! Накопление способов использования очень важно для нас.
В принципе, это возможно сделать. Но здесь может быть другая засада — некоторые радиусы не имеют возможности различать источник запроса — отвечают на любой Access-Request как будто он приходит из одного места (хм… получилось как-то двусмысленно, но в данном контексте даже хорошо ;). В этом случае такой радиус может послать циске такое, что она долго будет плеваться…
Можно также сделать на стороне fastDPI настраиваемый vendor-specific атрибут, в котором должна находиться строка определенного формата, и выкусывать из этой строки regexp'ами то, что нам нужно.
isany
Я, конечно, во всех этих DPI не эксперт, но мне понравилось название проекта :)