Я планирую разработать сеть Wi-Fi из нескольких зданий для объекта с несколькими тысячами посетителей (каждый посетитель остается на сайте в течение месяца). Мне нужно убедиться, что ни один пользователь не потребляет огромную пропускную способность. Если это так, мне нужно иметь возможность изолировать / идентифицировать устройства (и связаться с пользователем). Также (или альтернативно) я хотел бы ограничить пропускную способность этого пользователя.
Есть ли простой способ добиться этого? У меня есть центральный DHCP-сервер на случай, если это поможет, а здания разделены на подсети. У меня есть маршрутизаторы Microtik между подсетями (но я могу их изменить)
Общие шаги: я не знаком с этим конкретным маршрутизатором, поэтому я перечислил общие цели.
Есть ли сейчас централизованное ведение журнала на IP-адресе шлюза, которое вы можете использовать? Записывается ли система в базу данных SQL?
Есть ли центральный сервер аутентификации, радиус-сервер? Если да, возвращает ли он уникальный идентификатор или вы можете использовать идентификатор входа в систему.
Вы должны сбросить данные в центральную базу данных, содержащую MAC-адрес Ethernet, также включая байты и байты. [идентификатор пользователя, пользователь с сервера / метода аутентификации]
После создания базы данных вы выполняете агрегированные запросы, отсортированные по байтам и MAC-адресам.
Вы можете создать свои собственные правила для байтов в байтах и байтов вне или просто создать совокупное количество обоих.
Вы хотите установить ограничения для пользователя, конкретного устройства или того и другого?
Когда у вас есть цели, вы можете создавать сценарии действий в сети с помощью QOS, diff-serv и помечать пакеты пользователей.
Установите общие правила: максимальная пропускная способность для каждого подключения. Сеть должна поддерживать QOS, Diffserv и WMM [было бы хорошо]
Маршрутизаторы, свитчи должны иметь возможности QOS, diffserv. Проверьте переключатели, чтобы увидеть, какое влияние оказывает изменение QOS, тегов diffserv на различные коммутаторы, маршрутизаторы и т. Д. Это может повлиять на вашу частоту и метод обновления. Вся причина внедрения состоит в том, чтобы обеспечить бесперебойную работу сети. Вы хотите убедиться, что этот тип сетевого управления не оказывает отрицательного воздействия на сеть.
Как часто вы хотите обновлять и применять?
Вы хотите принудительно применить при следующем входе в систему или в режиме реального времени / полуреального времени? При входе в систему проверьте флаги SQL: флаг чтения байтов или флаги правил.
Вы хотите предупредить пользователя о правилах? если да, создать предупреждение при пороговом процентном соотношении использования [однако вы решите учитывать использование]
Создавать триггеры для запросов
Скрипт результатов на сетевые устройства с использованием SNMPv3 или альтернативного метода.
Я сделал несколько из них по разным причинам на протяжении многих лет. В одном случае мы поместили ящик посередине, чтобы разгрузить дополнительную рабочую нагрузку, вызванную общим процессом. Компьютер выступал в роли фильтра. Мы также добавили метод обнаружения мертвого шлюза перед фильтрующим компьютером. Если бы он был отключен, трафик шел бы прямо на шлюз, минуя систему фильтрации. Как указывалось ранее, общая цель этих проектов - обеспечить надежность и стабильность для всех пользователей в целом.