следующая ситуация: Мы группа студентов, управляющих подключением к Интернету для местных общежитий, всего около 2000 конечных пользователей.
У нас есть система баллов по трафику, баллы за каждую загрузку или отключение МБ, новые баллы добавляются по часам. На данный момент мы блокируем доступ пользователя в Интернет, когда он потратит все свои баллы (поместив его в политику REJECT в iptables на нашем маршрутизаторе шлюза Debian).
Мы хотим только ограничить пропускную способность пользователя. Как лучше всего это сделать?
Простым ответом было бы установить ограничение скорости для порта коммутатора пользователя (в основном Cisco Catalyst 3550). Однако это нежелательно, поскольку трафик внутри нашей собственной сети и в университетскую сеть должен оставаться неограниченным. Есть ли способ ограничить пропускную способность только для пакетов с определенным диапазоном IP-адресов назначения или источника (т.е. как исходящие, так и входящие) в Cisco IOS? Ничего не нашел.
Другой способ - контролировать трафик на нашем маршрутизаторе шлюза. На ум приходит несколько решений:
tc или tcng - похоже, что оба имеют довольно загадочный синтаксис и не предлагают хороших функций для управления трафиком по IP. Выделенный QDisc для такого количества людей, вероятно, довольно сильно замедлит работу маршрутизатора. Более того, документация по обоим сильно устарела.
shorewall - похоже, имеет довольно аккуратный синтаксис для конфигураций, однако я не уверен, может ли он обрабатывать такой объем трафика и пользователей и подходит ли он для ограничения трафика по IP
pfSense - похоже на ОС, предназначенную для таких целей, как наша. Однако это потребует от нас полной переустановки шлюзового маршрутизатора. У нас нет других систем BSD, и pfSense также должен иметь очень хорошие возможности учета трафика (в настоящее время мы используем там fprobe-ulog и ulog-acctd).
Какой у вас опыт? Какое решение соответствует нашим потребностям и его легче всего обслуживать? У вас есть другие идеи?
Если вам нужна дополнительная информация о нашей системе, не стесняйтесь спрашивать.
Заранее спасибо.
РЕДАКТИРОВАТЬ: Я реализовал систему с iptables и tc.
У каждого пользователя есть / 28-подсеть, IP-адрес VPN (начиная с 10.0.0.0/8) и внешний IP-адрес, все они управляются через одну цепочку iptables. В этой цепочке есть только одно правило, простое RETURN.
Каждые пять минут скрипт Python считывает счетчики байтов этих правил. Он сбрасывает счетчики и обновляет учетную запись точки трафика пользователя в нашей базе данных PostgreSQL.
Если баланс баллов пользователя уменьшается ниже определенного порога, для этого пользователя создаются два класса tc (один для входящего, один для исходящего интерфейса на нашем маршрутизаторе шлюза), IP-адреса вводятся в фильтры tc, принадлежащие этим классам. Скорость классов ограничена HTB.
По сравнению с предыдущей системой с fprobe-ulog и ulog-acctd это намного быстрее, так как подсчет байтов выполняется iptables.
Скорость сети значительно улучшилась для наших пользователей.
Я не уверен, насколько вы заинтересованы в перенастройке всей вашей установки (например, в замене Debian), или насколько возможно было бы разместить что-то подобное за вашим шлюзом, но FreeBSD имеет функцию в ipfw, известную как пустышка. Поскольку похоже, что вы не хотите получать выделенный аппаратный формирователь трафика, это может быть вариантом для вас. В настоящее время мы используем его для подавления входящего и исходящего SMTP-трафика через один из наших прокси-шлюзов, чтобы устаревающая серверная система NFS не перегружалась и не перестала отвечать.
С помощью некоторых сценариев и интеллектуальной конфигурации ваших наборов правил можно было бы управлять трафиком тысяч отдельных IP-адресов.
tc должен работать нормально .. Я считаю, что вы хотите изменить свои текущие правила iptables для маркировки, а не REJECT трафика, тогда вы можете использовать небольшое количество правил tc для применения формирования трафика к этим отмеченным потокам.
также посмотрите ipset для управления списком ограниченных пользователей http://ipset.netfilter.org/
На мой взгляд, dummynet - очень хорошее предложение. Но я уверен, что iptables способны формирование трафика тоже, так что вы можете просто сделать это на своем debian box.
При таком большом количестве пользователей большинство простых программных вещей начнет выходить из строя.
Рассмотрите возможность использования Packeteer и подобных устройств. В наши дни они почти дороже, чем просто покупка большей пропускной способности (в США и Европе у нас, бедняков в Австралии, все еще очень высокие ставки).
Я должен спросить, что мы используем, но у наших сотрудников ResTek есть устройство на границе Интернета, которое выполняет функции качества обслуживания. Он имеет приоритет по умолчанию для неклассифицированных потоков и устанавливает приоритеты для другого трафика на основе правил. Это приоритетная функция, которая действительно продает его, поскольку они также управляют кластером кэширования на основе Squid, который указан как наивысший приоритет в пограничном устройстве. Затем у людей в их сети есть выбор: просматривать веб-страницы со стандартным (и несколько отстойным) приоритетом или использовать прокси-сервер и получать очень быстрый ответ. Они также принимают приоритетные запросы игрового сервера, поскольку они чувствительны к задержкам, но, естественно, имеют низкую пропускную способность.
Обработка запросов игрового сервера требует значительного объема работы, но она постепенно уходит на второй план, поскольку все больше и больше игр отходят от частных серверов. В целом я слышал, что для них это работает очень хорошо. Они могут препятствовать тому, чтобы такие вещи, как BitTorrent, вытесняли весь другой трафик, и при этом сохраняли высокую скорость загрузки YouTube.
Трафикпанель кажется решением. Среди других особенностей:
Собственно, никогда не пробовал, но выглядит нормально.