Squid3 "режет" скорость
-
Помогите разобратся в причине вот такого явления:
Имеется свежеустановленная 2.2.6-RELEASE (amd64) со squid3 (4.7).
В трафик менеджемент значение Per-Host Throttling равно 140.
В обычном режиме (настройки прокси указываются в браузере) скорость соответсвует установленной, и например в спидтесте составляет ололо 1-1,1MBps, а в менеджере загрузок держится в районе 135-138 КБайт/с.Если же перевести в прозрачный режим (настройки браузера - без прокси, в качестве шлюза и днс - машина на pfSense)- начинаются чудеса. В спидтесте скорость падает до 0,6 Mbps, а скорость закачки "прыгает" от 80 до 115КБайт/с (среднее где-то 90-95). При этом график в Traffic Graph "скачет" пилообразно, от 0 до 1,5MBps.
Отказыватся от транспарент не хочется.
Подскажите как побороть?
Заранее благодарен! -
А если исп. Limiter ?
-
А если исп. Limiter ?
Limiter не дружит с кальмаром. Последняя рабочая версия pfsense, если не ошибаюсь, была 2.1.5, где третий кальмар с лимитером вместе могли работать. Кто-то говорил, что баг пофиксен с Squid 2 версии, но 3 все так же не дружит. Позавчера в этом убедился - интернет тупо не работает у клиентов, когда настроил Squid 3 (limiter ранее стоял и работал).
-
2 NiXeon
Спасибо за инф-цию. -
Переставил pfSense по новой, из пакетов только RRD, bandwithd и 3ий сквид.
Настройки транспарент и мен ин миддл пока вообще не трогал. Только основные настройки скивда.
При использовании Per-Host Throttling все так-же режет скорость, все такой-же пилообразный график.
Кто нибудь может подтвердить такую роботу 3го сквида при использовании Per-Host Throttling ? ??? (При значении Overall bandwidth throttling отличным от 0, ситуация такая же)
Или это могут быть особенности, например, железа (попробую на выходных на другом).Limiter не дружит с кальмаром.
Потом попробовал лимитер, у меня с лимитером работает.
С вот с таким правилом:
Но это только часть решения. Как можно ограничить всех пользователей squid`а, допустим 10Мбитами.
Т.е. на одного не больше 1, на всех не больше 10.
Лимитером как я, понимаю можно ограничить всех, но при этом один пользователь может занять всю полосу, если она никому не нужна. А потом по мере "поступления" новых пользователей будет делить ее с ними. -
Limiter не дружит с кальмаром. Последняя рабочая версия pfsense, если не ошибаюсь, была 2.1.5, где третий кальмар с лимитером вместе могли работать. Кто-то говорил, что баг пофиксен с Squid 2 версии, но 3 все так же не дружит. Позавчера в этом убедился - интернет тупо не работает у клиентов, когда настроил Squid 3 (limiter ранее стоял и работал).
Спустя столько времени я снова вернулся к этому вопросу. И, к своему удивлению, нашел его решение. В данный момент работает и прокси, и лимитер. Ну, и впн. Наткнулся на решение в каком-то турецком видео на ютубе, которое, почему-то, было заминусовано наполовину.
Итак, в чем суть. Я создал шейпер на интерфейсе. Вернее как, задал общую скорость на нем. Затем, добавил две очереди (думаю, можно было и одну оставить, не проверял). В общем, задав на интерфейсе общую скорость (я ее завысил на всякий), я "отрезал кусок" канала в лимитер (out_3_lan). Вторую очередь (full_speed) я создал для того, чтобы задать ее по -умолчанию, ибо pfsense ругается на отсутствие такового, ну и тоже завысил. Я так понял, что общая сумма этих очередей не должна превышать общую скорость, заданную на канале. И да, я несколько раз забывал поставить галочку "Enable/disable discipline and its children".
Все. А затем нужно эту очередь (или как правильно назвать этот Queue) добавить в правило клиентам (Firewall / Rules / Lan -> нужная группа). Так же, для корректной работы прокси пришлось добавить правило на 3128-3129 порты, которое все разрешает. Не знаю почему раньше работало (или сейчас без него не работает).
Так же, выходит, что эта "очередь" режет общую пропускную способность для всей выбранной группы на 3 Мбита, а значит, способ подходит к предыдущему сообщению :) Хотя поздновато ответил.
UPD.: сейчас сообразил, пока писал пост, что, скорей всего, раньше лимитер на работал как раз-таки из-за отсутствия разрешающего правила на 3128-3129 порты (ну, те, что заданы в прозрачном прокси для http и https). Думаю, стоит попробовать сначала добавить это правило, и посмотреть - заработает ли прокси с лимитером.
-
Limiter не дружит с кальмаром. Последняя рабочая версия pfsense, если не ошибаюсь, была 2.1.5, где третий кальмар с лимитером вместе могли работать. Кто-то говорил, что баг пофиксен с Squid 2 версии, но 3 все так же не дружит. Позавчера в этом убедился - интернет тупо не работает у клиентов, когда настроил Squid 3 (limiter ранее стоял и работал).
Спустя столько времени я снова вернулся к этому вопросу. И, к своему удивлению, нашел его решение. В данный момент работает и прокси, и лимитер. Ну, и впн. Наткнулся на решение в каком-то турецком видео на ютубе, которое, почему-то, было заминусовано наполовину.
Итак, в чем суть. Я создал шейпер на интерфейсе. Вернее как, задал общую скорость на нем. Затем, добавил две очереди (думаю, можно было и одну оставить, не проверял). В общем, задав на интерфейсе общую скорость (я ее завысил на всякий), я "отрезал кусок" канала в лимитер (out_3_lan). Вторую очередь (full_speed) я создал для того, чтобы задать ее по -умолчанию, ибо pfsense ругается на отсутствие такового, ну и тоже завысил. Я так понял, что общая сумма этих очередей не должна превышать общую скорость, заданную на канале. И да, я несколько раз забывал поставить галочку "Enable/disable discipline and its children".
Все. А затем нужно эту очередь (или как правильно назвать этот Queue) добавить в правило клиентам (Firewall / Rules / Lan -> нужная группа). Так же, для корректной работы прокси пришлось добавить правило на 3128-3129 порты, которое все разрешает. Не знаю почему раньше работало (или сейчас без него не работает).
Так же, выходит, что эта "очередь" режет общую пропускную способность для всей выбранной группы на 3 Мбита, а значит, способ подходит к предыдущему сообщению :) Хотя поздновато ответил.
UPD.: сейчас сообразил, пока писал пост, что, скорей всего, раньше лимитер на работал как раз-таки из-за отсутствия разрешающего правила на 3128-3129 порты (ну, те, что заданы в прозрачном прокси для http и https). Думаю, стоит попробовать сначала добавить это правило, и посмотреть - заработает ли прокси с лимитером.
Вы перепутали limiter с очередями. И проблема больше не со squid, а с правилами nat-rdr на локальном интерфейсе. Если прокси работает в непрозрачном режиме никаких проблем с лимитером.
-
Вы перепутали limiter с очередями. И проблема больше не со squid, а с правилами nat-rdr на локальном интерфейсе. Если прокси работает в непрозрачном режиме никаких проблем с лимитером.
Не перепутал, а добавил очереди плюсом к лимитеру в правилах. Хотя проблема скорей всего в правилах на 3128-3129 порты. Прокси в прозрачном режиме. По-крайней мере речь про него здесь шла, как я понял
-
2 NiXeon
Scheduler type я бы выбрал faltq . HFSC некорректно работает в pf. А в дочерн. очередях исп. codelq. -
2 NiXeon
Scheduler type я бы выбрал faltq . HFSC некорректно работает в pf. А в дочерн. очередях исп. codelq.Вот как, спасибо. Подправил у себя. :) А для справки, как некорректно работает?
-
2 NiXeon
Scheduler type я бы выбрал faltq . HFSC некорректно работает в pf. А в дочерн. очередях исп. codelq.Вот как, спасибо. Подправил у себя. :) А для справки, как некорректно работает?
В закладки
https://forum.pfsense.org/index.php?topic=111231.0
https://forum.pfsense.org/index.php?topic=110938.0 -
В закладки
https://forum.pfsense.org/index.php?topic=111231.0
https://forum.pfsense.org/index.php?topic=110938.0Спасибо!
-
PF 2.3.2 непонятно как при не работающем Limiters со сквидом (нужен прозрачный прокси) ограничить скорость юзерам в сети.
