СКАТ - Мониторинг, веб-интерфейс, маршрутизация

СКАТ — Мониторинг, веб-интерфейс, маршрутизация

Мониторинг

Для отслеживания состояния СКАТ имеется шаблон системы мониторинга Zabbix, который позволяет снимать основные параметры с самого DPI. Также можно использовать шаблон Zabbix для Linux Centos. Имеется возможность снимать данные о характеристиках трафика с помощью IPFIX/Netflow.

Веб-интерфейс

Для более понятного и простого управления системой имеется веб-интерфейс, через который можно вносить изменения в систему, а также просматривать основные ее параметры. Такой способ управления подходит людям, которые плохо знакомы с консолью *nix, но хотят иметь возможность создать оповещения для абонентов или провести базовые изменения конфигурации до того момента, как более опытный специалист сделает тонкую настройку через консоль в случае аварии или проблемы.

Привожу пару снимков меню конфигурации, на которых видно, что при наличии знаний основных принципов системы DPI СКАТ с помощью веб-интерфейса можно выполнить полную ее конфигурацию.

СКАТ - dashboard интерфейса GUI
Рисунок 1. Dashboard интерфейса GUI

СКАТ - GUI основная кофигурация
Рисунок 2. GUI основная кофигурация

 
Ввод в эксплуатацию и маршрутизация

Мы сконфигурировали DPI, сделали его перезапуск и получили готовую к работе систему.

Осталось только настроить интеграцию с биллингом. Для этого мы используем скрипт на python, который регулярно выгружает всех абонентов по API, а именно – их IP-адреса и параметры скорости, выискивает изменения и применяет их на DPI. Конечно, есть некие нюансы, но это нюансы уже конкретной инсталляции. Суть в том, что вы можете решить этот вопрос сходным образом (скриптом чуть ли не на любом языке, запуская его на самом DPI) либо загружать команды удаленно по ssh с биллинга.

Мы подошли к самому важному этапу – вводу оборудования в эксплуатацию на живой сети.
Имея два устройства, хочется сделать балансировку их рузки, что можно осуществить средствами агрегации линков (LAG). DPI в нашем случае устанавливается в разрыв, между ядром и пограничным маршрутизатором.


Рисунок 3. Схема внедрения

Для проверки работоспособности DPI с нашей конфигурацией попробуем пропустить трафик через нее. Для этого используем policy-based routing (PBR).
Мы имеем два L3-устройства (в нашем случае это два L3-коммутатора Cisco) в качестве ядра и пограничного маршрутизатора. Сделаем два vlan и, соответственно, два L3-домена для разных DPI.
Таким образом мы получаем возможность манипулирования трафиком с помощью маршрутизации и PBR.


Рисунок 5. Схема сети

Для проверки мы решили выпустить через СКАТ трафик подсети 192.0.2.0/24.
Приведем некие фрагменты изначальной конфигурации (синтаксис Cisco IOS).

Конфигурация SVI на L3 коммутаторах.

На ядре сети:
interface Vlan10 description CORE-SKAT-BORDER ip address 198.51.100.2 255.255.255.252
interface Vlan20 description CORE-SCE-BORDER ip address 198.51.100.6 255.255.255.252

На пограничном маршрутизаторе:
interface Vlan10 description BORDER-SKAT-CORE ip address 198.51.100.1 255.255.255.252
interface Vlan20 description BORDER-SCE-CORE ip address 198.51.100.5 255.255.255.252

Конфигурация маршрутизации

Со стороны ядра:
ip route 0.0.0.0 0.0.0.0 198.51.100.5

Со стороны пограничного маршрутизатора:
ip route 192.0.2.0 255.255.255.0 198.51.100.6
ip route 198.51.100.0 255.255.255.0 198.51.100.6
ip route 203.0.113.0 255.255.255.0 198.51.100.6

На ядре создаем ACL, который будем вызывать в route-map для осуществления PBR, чтобы трафик от подсети 192.0.2.0 и до нее пошел через СКАТ, в ACL мы «запрещаем» прохождение трафика от интересующей нас подсети к другим локальным подсетям и разрешаем прохождение трафика от этой подсети ко всем остальным (Интернет).

Таким образом, только этот трафик будет обработан в соответствии с политикой PBR:
ip access-list extended PBR_ACL
deny ip 192.0.2.0 0.3.255.255 198.51.100.0 0.0.0.255
deny ip 192.0.2.0 0.3.255.255 203.0.113.0 0.0.0.255
permit ip 192.0.2.0 0.0.0.255 any

Переходим к route-map:
route-map PBR permit 10
match ip address PBR_ACL
set ip next-hop 198.51.100.1

Применяем route-map на интерфейс, через который трафик этой подсети приходит на ядро. Если таковых несколько, то применить нужно на каждом. Необходимо понимать, что оборудование способно работать с этим PBR «в железе», чтобы не возникло проблем с производительностью сети и не произошло падения ядра.
interface Vlan10
ip policy route-map PBR

На стороне пограничного маршрутизатора:
ip route 192.0.2.0 255.255.255.0 198.51.100.2