Веб-интерфейс провайдера для сетей Cisco и LanBilling

Пару-тройку лет назад, когда я занимался обслуживанием интернета у провайдера,  возникла потребность упростить обслуживание абонентов в университетских общежитиях. Для этого я написал сайт, в котором объединил функции управления и сбора информации с коммутаторов доступа (в основном cisco 2960) и биллинга LanBilling 1.9. Этот пост не является инструкцией по повторению подобного сайта, а, скорее, попытка засвидетельствовать что получилось и какой функционал по силам написать за пару месяцев работы.

Архитектура сети такая: все абоненты подключены к управляемым портам cisco с проводной авторизацией по 802.1x с получением ip-адреса по DHCP, коммутаторы авторизуют пользователя через Radius-сервер LanBillinga. LanBilling, при успешной авторизации, создает ACL на коммутаторе ядра сети и выпускает абонента в интернет.

Прежде чем рассказывать как стало, расскажу как было c обслуживанием:
Звонит человек, у которого чего-то не работает, идешь в веб-интерфейс ланбиллинга смотреть  подключен ли вообще этот человек, просишь человека подключиться, а админа биллинга посмотреть в консоли LanBillinga есть ли что в логах странное при подключении, если нету, смотришь по xls-файлу к какому коммутатору подключен человек, прешься телнетом или ssh на коммутатор и смотришь включен-ли порт, есть ли ошибки на порту, что в логах коммутатора и т.п.
В общем, все это очень долго, хлопотно, неэффективно и захотелось создать систему, в которой все можно было делать на одном сайте.

На момент создания всего этого из CMS я более менее как-то знал drupal6 и php. Но нем и решено было делать в виде написания модулей и сниппетов (это блоки кода на странице).

Захотелось:

  • Поиск логина среди установленных сессий LanBilling.
  • Закрытие установленных соединений LanBilling.
  • Отображение всех подключенных пользователей по конкретному адресу (дом/комната).
  • Поиск в логах LanBilling с фильтрацией по логину или отображение всех последних событий с консоли биллинга.
  • Поиск в централизованном syslog-сервере событий с фильтрацией по порту коммутатора (обычно ищется err-disable из-за второго мака на порту)
  • Поиск среди установленных интернет-сессий пользователя через специальный сетевой сервис (нужно, когда пользователь говорит что не работает интернет, а сервис показывает что у него реально соединения установлены).
  • Тестирование кабеля средствами коммутатора

В последствии в систему были добавлены  функции, связанные с обнаружением прокси-сервисов, торрент-раздач, предсказании ОС пользователя и база знаний на базе вики.

Общий вид интерфейса такой (все кликабельно):
Это окно просмотра конкретного коммутатора. Сразу показывается какие порты в admin down, к каким никто не подключен, к каким какой логин в биллинге подключен, счетчики пакетов (unicast, multicast, error все отдельно по input и output), мак компьютера. Также у каждого порта есть ссылка show, нажатие которой выведет результат команды на порту show interface. По каждому логину есть кнопка убить сессию через биллинг.

На следующем рисунке часть интерфейса, отвечающая за поиск пользователя по его общежитию и номеру комнаты:
Поиск выдал две розетки в одной комнате, к одной никто не подключен, а к второй подключен пользователь с логином danil1393, которому был выдан адрес 212.192.69.109. При этом можно сразу провести тестирование кабеля (обычный для cisco tdr test) или, по нажатию кнопки, "пингануть" пользователя (ajax, без перезагрузки страницы).
Важная фича: можно запустить отображение логов с коммутатора (ссылка "смотреть логи") с автоматическим обновлением последних логов через каждый 5 секунд (тоже ajax). Используется тогда, когда пользователь не может подключиться и коммутатор в логах хотябы напишет была ли реально попытка подключения и почему она не удачна. Как и на рисунке выше, ссылка "show" выполнит через ajax команду shot interface Fa0/9, в которой будет много полезной информации.

На следующем рисунке просто список сессий пользователей в биллинге. Черный прямоугольник в колонке nas- замазанные ip-адреса коммутаторов, кликнув по которым можно перейти к просмотру коммутатора, на котором находится пользователь
Здесь сразу видно, что у пользователя 162342 в биллинге сразу две сессии и он по DHCP не получил ip-адрес (0.0.0.0). Значит у этого пользователя какие-то проблемы.
На этом же экране баланс пользователя и возможность убить его сессию.

На следующем рисунке логи из консоли биллинга:
Логи подгружаются по нажатию кнопки "Обновить" ajax-ом, без перезагрузки страницы. Если в качестве логина указать all, выведутся все логи без какого либо фильтра. Также можно искать по конкретному логину (чаще всего так и используется).
На данном рисунке, во второй строчке, видно что пользователь неправильно настроил 802.1x и, в качестве логина использует имя компьютер <host/Рома-ПК>, за что и получил Access-Reject.

Кроме описанных вещей, можно еще увидеть иконку "Карты" - это поиск по ФИО в базе системы контроля доступа, построенной на отечественном ПО "Орион".

Теперь как это все делалось: 

Отдельная виртуальная машина c Linux, mysql, drupal6 и кучка самописных модулей и сниппетов. Для сбора информации с коммутаторов используется snmp, а то что нельзя им собрать, собирается командами по telnet/ssh. Все взаимодействие с биллингом осуществляется через http-запросы. Взаимодействие с системой контроля доступа осуществляется путем прямого подключения в БД MS SQL. syslog-сервер установлен там же где и сайт. Большая часть функций использует разделение прав доступа на уровне ядра drupal. Т.е. конкретному пользователю можно разрешить только часть из этого функционала. При желании, drupal можно подключить к LDAP.

На создание основного функционала системы ушло около 2 месяцев. Некоторые отдельные вещи добавлялись уже потом, суммарно заняв еще где-то месяц. Система пережила один рефакторинг (1,5 недели) с целью избавления от наиболее серьезных косяков кодирования, которые я допустил по неопытности обращения с drupal.

Комментарии

Популярные сообщения из этого блога

Обзор почтового клиента Pronto Pro!

Подключаем ZFS over iSCSI на Oracle Linux 8 (CentOS) в Proxmox

Архитектура катастрофоустойчивого сервиса