Внимание!

Эта статья разделена на две части:

• В первой части я изучаю ограничение скорости на тестовой сети из одного pfSense v.: 2.1.5 и двух клиентских компьютеров. pfSense в этом случае чистый, т.е. все действия выполняются на только что установленном pfSense v.: 2.1.5. Отмечу, что хоть данная часть и написана для pfSense версии 2.1.5, в версии 2.2.6 — всё делается точно так же. Можете не повторять то что в ней написано, это лишь для понимания процесса.
  
• Во второй части я применяю полученные знания на моём pfSense, копорый я описываю начиная с первой статьи.

Часть I. Изучение

Судя по бурному обсуждению на интернет-форумах темы ограничения скорости пользователей, данная задача не такая уж и простая. Основная проблема — ограничение скорости torrent клиентов, которые забивают всю сеть. При этом в интернете отсутствует доступная инструкция об ограничении трафика пользователей, включающей в себя pfSense шейпинг для HTTP, HTTPS, torrent и всего остального. Похоже я сейчас стану первопроходцем, описавшим этот процесс для чайников)))

Итак, в интернете одни предлагают резать трафик пользователей через шейпер Firewall -> Traffic Shaper -> Limiter, другие заметили что таким способом не режется torrent-трафик и предлагают использовать Layer7. Целую неделю я мучился и проверял их теории и советы, в итоге вывод оказался таким: Если Вы хотите действительно качественно ограничить скорость для пользователей, то ни Limiter, ни Layer7 Вам НЕ ПОМОГУТ! Для решения этой задачи следует использовать Firewall -> Traffic Shaper -> Wizards и Firewall -> Traffic Shaper -> By Interface

Позволю себе отступление: в pfSense версии 2.2.6 шейпер Firewall -> Traffic Shaper -> Limiter не адекватно работает с прозрачным прокси сервером Squid. Зато прекрасно работает в версии 2.1.5. Но так как мы не будем использовать Limiter, то и версия 2.1.5 вам не к чему.

Основные теоретические знания описаны тут:

https://forum.pfsense.org/index.php/topic,33870.0.html

http://www.thin.kiev.ua/router-os/50-pfsense/432—hierarchical-fair-service-curve-hfsc-openbsd.html

Для ограничения скорости будем использовать Очереди (Queues) и Планировщик (Hierarchical Packet Scheduler (HFSC))

Я не буду сразу приводить готовый перечень настроек, необходимый для ограничения скорости пользователей, а проведу Вас по пути моего собственного изучения этой фишки, что даст Вам более обширные представления о проблеме.

 

pfSense ограничение скорости пользователей

Схема моей тестовой сети выглядит так:

http://beta.speedtest.net/ показывает Download 6.35 Mbps, Upload 6.57 Mbps

Открываем WEB-интерфейс и идем в Firewall -> Traffic Shaper -> Wizards, нажимаем traffic_shaper_wizard_dedicated.xml

На первой странице мастера вводим Enter number of WAN type connections: 1 (так как у нас один WAN-порт), жмём Next

Далее нам нужно выбрать Планировщик и указать скорость Upload и Download, предоставляемую Вашим провайдером. Выбираем HFSC для обоих интерфейсов. Теперь насчет скорости: Очень важно указать этот параметр чуть меньшим, чем максимальная пропускная способность канала, оптимальное значение должно быть 96% пропускной способности канала.

Выдержка из статьи http://www.thin.kiev.ua/router-os/50-pfsense/432—hierarchical-fair-service-curve-hfsc-openbsd.html

Почему? Вы хотите использовать очереди как средство ограничения канала.
Когда вы отправляете данные и нагружаете канал, маршрутизатор, с которым вы соединяетесь, решает, какие пакеты идут первыми, хотя именно этого мы и хотим от своего HSFC.
Мы можем не доверять вышестоящему маршрутизатору сортировать ваши пакеты, что происходит в случае, если не используется HSFC на нашей стороне.

Итак, мы указываем скорость меньше полной полосы пропускания.
«Неужели мы потратим часть полосы впустую?», можете спросить вы. Да, но необходимо помнить, что мы удостоверяемся, что маршрутизаторы провайдера отсылают пакеты в порядке, котором определяем мы, а не они.
Это имеет значение для пакетов ACK и фактически увеличит доступную полосу пропускания на загруженных каналах.

Так как наша скорость Download 6.35 Mbps, Upload 6.57 Mbps, то, не заморачиваясь, укажем её как 6 Mbps в ту и другую сторону:

Затем нам предложат выделить канал для Voice over IP, пропускаем этот пункт, нажав Next

Нам предложат выделить канал Penalty Box, пропускаем этот пункт, нажав Next

На странице Peer to Peer networking ставим галочку напротив Enable, проматываем вниз и ставим галочку напротив BitTorrent:

Не надо тут ставить ничего большего, чтобы не засорять себе мозги, жмём Next.

Network Games и Raise or lower other Applications пропускаем, нажав Next, затем Finish.

Нас перебросит на страницу Status: Filter Reload Status. Дожидаемся появления надписи Done. The filter rules have been reloaded., жмём Queue Status.

Теперь самое время загрузить интернет. Включаем на обоих компьютерах uTorrent и качаем фильмы на полной скорости, забивая тем самым весь канал. Средняя скорость закачки на обоих компьютерах около 300 КБ/s Картина должна быть примерно такая:

Как видим, канал в 6 Mbps полностью забит торрентами.

Ограничение скорости клиентов pfSense

Теперь приступим непосредственно к ограничению скорости.

Допустим, я хочу сделать пул для этих двух компьютеров шириной канала в 1Mbps, т.е. выделяется труба размером 1Mbps и к ней подключаются два компьютера (192.168.0.19 и 192.168.0.9).

Для начала идём в Firewall -> Rules -> Floating и удаляем созданные ненужные правила. (по идее эти правила должны были ограничивать нам скорость закачки торрентов, но torrent-клинеты нынче умные и не ограничиваются портами 6881-6999, поэтому и фигачат в полную скорость). Жмём Apply Changes

Далее идём в Firewall -> Aliases-> вкладка IP и создаём тестовый алиас:

• Name: test_pool
• Type: Hosts
• IPs: 192.168.0.19 и 192.168.0.9

Жмём Save, затем Apply changes

 Теперь идём в Firewall -> Rules-> вкладка LAN и создаём правило вверху списка:

Параметры указываем такие:

• Action: Pass
• Protocol: any
• Source: Single host or alias -> test_pool
• Ackqueue/Queue: none / qP2P

Жмём Save

Жмём Apply changes:

Заметьте, созданное нами правило должно находиться выше общеразрешающего правила, иначе оно будет проигнорировано.

Теперь заставим наших клинетов оборвать установленные соединения и подключиться заново. Для этого жмём на кнопку Reset на странице Diagnostics -> States -> вкладка Reset States, галочка Firewall state table должна быть установлена.

После этого действия интернет на данных двух компьютерах начал жутко тормозить, а скорость закачки торрентов упала до 15 — 25 КБ/с. Speedtest.net при выключеных торрентах показал скорость Download 0.17 Mbps, Upload 0.19 Mbps.

Выключите пока закачку торрентами.

Можно начинать радоваться, так как никакой трафик с этих компьютеров теперь никак не может забить канал в 6Mbps, но теперь нам как-то нужно настроить скорость. Идём в Firewall -> Traffic Shaper -> вкладка By Interface:

Дела такие:

• То, что находится под интерфейсом WAN отвечает за Upload, т.е. исходящий трафик
• То, что находится под интерфейсом LAN отвечает за Download, т.е. входящий трафик
• Очередь qACK является самой приоритетной, т.е. пакеты идущие по этой очереди обрабатываются в первую очередь и совсем не тормозят даже при полностью загруженном канале. Туда Обычно засовывают самые важные пакеты типа DNS, ICMP, и прочее
• Очередь qDefault имеет средний приоритет и собирает все пакеты которые не попадают в другие очереди. Собирает все пакеты потому что в настройках очереди указана галочка Default queue
• Очередь pP2P по задумке мастера, которым мы пользовались, имеет самый низкий приоритет и по-умолчанию собирал пакеты с портов 6881-6999, но мы изменили это на сбор всего трафика с алиаса test_pool. Собственно поэтому у нас интернет так тормозит.

Теперь нам надо как-то увеличить приоритет трафика для наших компьютеров и мы будем менять настройки очереди qP2P. Заходим в WAN -> qInternet -> qP2P:

Давайте разбираться с параметрами (материал из статьи http://www.thin.kiev.ua/router-os/50-pfsense/432—hierarchical-fair-service-curve-hfsc-openbsd.html):

• Enable/Disable queue and its children — Включает или выключает данную очередь и все её подочереди
• Queue Name — Имя очереди
• Priority — Приоритет очереди, это уровень, определяющий порядок, в котором сервис будет обслуживаться относительно других очередей. Чем выше значение, тем выше приоритет. Эта директива – простой способ указать, какие пакеты будут отправлены первыми, по сравнению с другими. Приоритет не задает полосу пропускания, но определяет порядок, в котором пакеты буферизуются перед отправкой. Диапазон приоритетов может принимать значения от 0 до 7. Приоритет 0 является самым низким приоритетом и назначается наименее важным данным. Если приоритет на задан, то в качестве значения по умолчанию используется 1 приоритет.
• Queue limit — количество «слотов», доступных для очереди, чтобы хранить отправляемые пакеты, когда количество доступной полосы пропускания для очереди было превышено. По умолчанию это значение равно 50. Когда на исходящем интерфейсе будет достигнуто максимальное значение полосы пропускания, или ее займут данные с более высоким приоритетом, qlimit поместит пакеты, которые очередь не может отослать, в память, занимая свободные слоты. Когда полоса пропускания будет доступна, qlimit слоты будут освобождены в том порядке, в каком они поступали. Если qlimit достигнет максимального значения qlimit, то пакеты будут отброшены. Рассматривайте использование qlimit как крайнее средство, но это альтернатива отбрасыванию пакетов. Кроме того, не думайте, что qlimit действительно способен решить проблему проблему перегрузки полосы пропускания и отбросов пакетов. Данное средство предназнчено для кратковременного хранения пакетов в момент перегрузки канала.
• Scheduler options
  • Default queue — очередь по умолчанию. Все, что не попадает в другие правила – попадает сюда. Эта директива должна использоваться только один раз.
  • Explicit Congestion Notification (ECN) — Явное Уведомление о Перегруженности — расширение протокола IP, позволяет обеим сторонам в сети узнавать о возникновении затора на маршруте к заданному хосту или сети без отбрасывания пакетов. Это дополнительная функция, которая используется только в том случае, когда обе конечные точки обмена информацией сообщают, что они хотят её использовать. Обычно, узлы TCP/IP сетей сообщают о возникновении затора путем отбрасывания пакетов. Если ECN сессия успешно установлена, поддерживающие расширение ECN маршрутизаторы могут сигнализировать о начале заторов устанавливая биты в заголовке IP, а не удаляя пакеты. Получатель пакетов информирует отправителя о заторе, который должен реагировать так, как будто был обнаружен сброс пакетов.
• Description — описание очереди
• Bandwidth -имеет два немного различных определения в зависимости от того, был ли данный параметр указан в родительской или дочерней очереди. Обратите на это внимание, чтобы избежать дальнейшей путанницы.
  • В родительской строке определяется суммарная пропускная способность для всех очередей интерфейса. Указывается общая пропускная способность, предоставляемая провайдером и не зависящая от скорости сетевого интерфейса.
  • В дочерней строке(ах) эта директива определяет максимальную скорость передачи информации в битах, которая будет обработана очередью в любой момент. Эта директива – фактически аналогична использованию «linkshare» с параметром (m2). Это значение не должно превысить значение родительской очереди и может быть определена как абсолютная величина или процент от полосы пропускания родительской очереди. Если значение не определено, то по умолчанию размер равен 100% полосы пропускания родительской очереди. Желательно назначить процент от вашей полной полосы пропускания каждой дочерней очереди, при этом не превысив суммарные 100% родительской очереди.
• Service Curve (sc)
  • Upperlimit — определяет количество полосы пропускания, которую очередь не может превысить. Например, вы устанавливаете почтовый сервер и хотите быть уверенным, что он не откусит больше 50% полосы пропускания, или у вас имеется активный пользователь p2p. Используя upperlimit можно будет препятствовать перегрузке канала.
  • Real time — размер полосы пропускания, которая гарантируется очереди независимо от того, в какой полосе нуждается любая другая очередь. Данный параметр может быть установлен от 0% до 80% полной полосы пропускания. Можно сказать, что вы хотите быть уверенным в том, что ваш веб-сервер получает 25KB/sec полосы пропускания независимо ни от чего. Определение значения realtime даст очереди веб-сервера полосу пропускания, в которой она нуждается, даже если другие очереди хотят совместно использовать ее полосу пропускания. Совсем не обязательно что данный размер полосы будет зарезервирован и не доступен для других очередей. Напротив, другие очереди вполне могут использовать этот зарезервированный канал, но когда кому-то понадобится передать по нему данные, то он мигом отберёт канал и будет передавать по нему.
  • Link share — этот параметр имеет тот же самый смысл, как и «bandwidth», указанный выше. Если вы определите параметры «bandwidth» и «linkshare» в одном правиле, то pf будет использовать директиву «linkshare m2». Это может вызвать беспорядок если у вас есть два различных параметра настройки в каждом. По этой причине мы не собираемся использовать «linkshare» в наших правилах. Единственная причина, по которой вы можете захотеть использовать «linkshare» вместо «bandwidth», это использование нелинейной кривой сервиса (nonlinear service curve).
  • параметры m1, d и m2 — директивы «realtime», «upperlimit» и «linkshare» могут использовать переменные m1, d, m2, где m2 которые управляет полосой пропускания, назначенной на очередь. m1и d являются дополнительными и могут использоваться, чтобы управлять начальным размером полосы пропускания. Для первых d миллисекунд очередь имеет полосу пропускания m1, после чего принимает значение, заданное в m2.

Теперь изменим настройки этой очереди следующим образом:

• Priority: 5
• Bandwidth: 1 Mbit/s
• Upperlimit: 1Mb
• снимаем галочку Link share
• Жмём Save, затем Apply changes

Теперь дублируем эти настройки для очереди LAN -> qInternet -> qP2P, сохраняем.

После этих действий Speedtest.net при выключеных торрентах показал скорость Download 0.92 Mbps, Upload 0.94 Mbps.

Запускаем торренты. Скорость закачки торрента на одном компьютере 55 КБ/с, на другом — 45 КБ/с, это означает что компьютеры из пула test_pool поделили канал шириной 1 Mbps между собой и забили его полностью! (Шикарно 🙂)

Если Вы попробуете при включенных торрентах поработать в интернете, то расстроитесь, что он дико тормозит. Конечно, ведь торренты забрали весь трафик на себя. Но это можно легко исправить, задав трафику по HTTP и  HTTPS более высокий приоритет над остальным трафиком (в том числе и торрент трафиком, т.к. конкретно его очень тяжело вычленить — он меняет порты и шифруется).

Постойте, а почему именно HTTP и  HTTPS, ведь кроме них есть ещё много полезного трафика, нельзя же чтобы он тоже тормозил под натиском торрентов. Чтобы не перебирать все полезные порты, обратимся к таблице https://ru.wikipedia.org/wiki/Список_портов_TCP_и_UDP. Мы можем заметить, что все полезные (общеизвестные) порты лежат в диапазоне от 1 до 1023, остальные — не на столько важны, чтобы делать их приоритетными.

Поэтому создадим новые дочерние очереди под LAN -> qInternet -> qP2P, что соответствует входящему Download трафику: Good (приотитетный трафик — с 1 по 1023 порты) и Bad (остальные порты).

Приоритезация трафика pfSense

Заходим в настройки очереди LAN -> qInternet -> qP2P и жмём кнопку Add new queue

Указываем следующие параметры:

• Ставим галочку Enable/Disable queue and its children
• Queue Name: Good
• Priority: 6 (главное чтобы эта цифра была выше чем у Bad)
• Ставим галочку Explicit Congestion Notification
• Bandwidth: 50% (Единственное, что нужно соблюдать — сумма Bandwidth дочерних очередей не должна превышать Bandwidth родителя. Поэтому удобно использовать проценты.)
• Service Curve (sc):
  • Upperlimit: ставим галочку
    • m2: 98% (Пакеты в очереди Good могут забивать до 98% общего (родительского) канала qP2P. 2% мы всё-таки оставим для Bad)
  • Real time: ставим галочку
    • m2: 50% (Пакеты в очереди Good, если нужно, отберут у других подочередей (в нашем случае у Bad) свои зарезервированные 50% ширины общего (родительского) канала qP2P для передачи данных. Это обеспечит хорошую работу портов 1-1023 даже при забитом торрентами канале.)

Жмём Save, затем Apply changes

Затем снова заходим в настройки очереди LAN -> qInternet -> qP2P и жмём кнопку Add new queue. Добавляем очередь Bad. Указываем параметры:

• Ставим галочку Enable/Disable queue and its children
• Queue Name: Bad
• Priority: 4 (главное чтобы эта цифра была ниже чем у Good)
• Ставим галочку Explicit Congestion Notification
• Bandwidth: 50% (сумма Bandwidth дочерних очередей не должна превышать Bandwidth родителя. Так как у Good — 50%, то для Bad осталось 50%.)
• Service Curve (sc):
  • Upperlimit: ставим галочку
    • m2: 98% (Пакеты в очереди Bad могут забивать до 98% общего (родительского) канала qP2P. 2% мы оставим для Good. Это для того чтобы нормально качались торренты при отсутствующей активности в очереди Good (т.е. по 1-1023 портам). Но как только появится активность по Good, она без проблем отберет свои зарезервированные 50% канала у любой соседней очереди (в нашем случае у Bad))

Жмём Save, затем Apply changes

Теперь нам нужно изменить правила фаервола для распределения прафика по созданным очередям Good и Bad. Идём в Firewall -> Rules-> вкладка LAN и редактируем наше правило для test_pool:

Меняем параметр Ackqueue/Queue на значение none / Bad

Жмём Save, затем Apply changes

Теперь создаём новое правило выше нашего правила для test_pool:

• Action: Pass
• Protocol: TCP/UDP
• Source: Single host or alias -> test_pool
• Destination port range:  from: 1 to: 1023
• Ackqueue/Queue: none / Good

Жмём Save, затем Apply changes. Должно получиться так:

Теперь нам нужно заставить наших клинетов оборвать установленные соединения и подключиться заново. Для этого жмём на кнопку Reset на странице Diagnostics -> States -> вкладка Reset States, галочка Firewall state table должна быть установлена.

 

Смотрим на наши торренты: Оба торрента делят канал шириной в 1Mb пополам: на одном компьютере у меня скорость 28 КБ/с, на другом 81 Кб/с. Теперь попробуем поработать в интернете: замечаем что теперь он уже так не тормозит, потому что трафик по портам 1-1023 является приоритетным к остальному трафику. В этом мы можем убедиться перейдя на страницу Status -> Queues

Мы сделали очереди для трафика на загрузку (интерфейс LAN), теперь нужно сделать то же самое для интерфейса WAN:

Теперь можно сделать контрольную перезагрузку и наслаждаться результатом! 🙂

 

Часть II. Настройки ограничения скорости на рабочем прокси

Я не буду расжовывать что да как, это было в первой части. Сейчас я приведу скриншоты настроек, которые у меня получились в pfSense 2.2.6, который мы с Вами настраиваем с первой статьи. Итак:

Firewall -> Aliases

Firewall -> Rules -> LAN

Данный набор правил пускает в интернет только тех, кто указан в Aliases. Чтобы пустить остальных, нужно включить последнее правило.

Трафик проходящий через порты 1-1023 и 3128 имеет более высокий приоритет над трафиком по остальным портам. я обозначил его как Good.

Теперь приведу правила для Good и Bad трафика.

Good:

Bad:

Firewall -> Traffic Shaper -> By Interface:

 

Я немного пересмотрел рекомендуемые в первой части настройки относительно родительского Bandwidth. Если указать пропускную способность канала, как рекомендовалось в 1 части, то все дочерние очереди должны делить её между собой. Таким образом, имея около 10-ти очередей, мы будем иметь по 600Kbps на каждую очередь. Это, конечно, не дело. Поэтому в родительском Bandwidth я указал огромное значение, чтобы сумма дочерних очередей была меньшей. А для ограничения пропускной способности родительских очередей я использую параметр Upperlimit

WAN:

WAN -> qInternet:

WAN -> qInternet -> qACK (такой же как LAN -> qInternet -> qACK):

WAN -> qInternet -> qDefault:

LAN:

LAN -> qLink:

LAN -> qInternet:

Теперь приведу настройки типовой очереди:

Good:

Bad:

То, что получилось в Status -> Queues:

 

P.S.: Чёта пока писал статью, дошло, что по-хорошему нужно создавать родительскую очередь для каждого подразделения с конкретной пропускной способностью, а уже в неё вкладывать Good и Bad. Хотя, вроде, и так неплохо работает.
 

Содержание

• 1. Введение pfSense
• 2. Установка pfSense
• 3. Настройка pfSense (разрешить ICMP)
• 4. Настройка L2TP в pfSense
• 5. Настройка прокси в pfSense
• 6. Интеграция pfSense в рабочую сеть
• 7. pfSense авторизация по MAC
• 8. pfSense ограничение скорости пользователей