Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Squid3 "режет" скорость

    Scheduled Pinned Locked Moved Russian
    13 Posts 5 Posters 3.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N Offline
      NiXeon
      last edited by

      @werter:

      А если исп. Limiter ?

      Limiter не дружит с кальмаром. Последняя рабочая версия pfsense, если не ошибаюсь, была 2.1.5, где третий кальмар с лимитером вместе могли работать. Кто-то говорил, что баг пофиксен с Squid 2 версии, но 3 все так же не дружит. Позавчера в этом убедился - интернет тупо не работает у клиентов, когда настроил Squid 3 (limiter ранее стоял и работал).

      1 Reply Last reply Reply Quote 0
      • werterW Offline
        werter
        last edited by

        2 NiXeon
        Спасибо за инф-цию.

        1 Reply Last reply Reply Quote 0
        • P Offline
          pbx
          last edited by

          Переставил pfSense по новой, из пакетов только RRD, bandwithd и 3ий сквид.
          Настройки транспарент и мен ин миддл пока вообще не трогал. Только основные настройки скивда.
          При использовании Per-Host Throttling все так-же режет скорость, все такой-же пилообразный график.

          Кто нибудь может подтвердить такую роботу 3го сквида при использовании Per-Host Throttling ? ??? (При значении Overall bandwidth throttling отличным от 0, ситуация такая же)
          Или это могут быть особенности, например, железа (попробую на выходных на другом).

          @NiXeon:

          Limiter не дружит с кальмаром.

          Потом попробовал лимитер, у меня с лимитером работает.
          С вот с таким правилом:

          Но это только часть решения. Как можно ограничить всех пользователей squid`а,  допустим 10Мбитами.
          Т.е. на одного не больше 1, на всех не больше 10.
          Лимитером как я, понимаю можно ограничить всех, но при этом один пользователь может занять всю полосу, если она никому не нужна. А потом по мере "поступления" новых пользователей будет делить ее с ними.

          1 Reply Last reply Reply Quote 0
          • N Offline
            NiXeon
            last edited by

            @NiXeon:

            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). Думаю, стоит попробовать сначала добавить это правило, и посмотреть - заработает ли прокси с лимитером.

            01.PNG
            01.PNG_thumb
            02.PNG
            02.PNG_thumb
            03.PNG
            03.PNG_thumb
            04.PNG
            04.PNG_thumb
            05.PNG
            05.PNG_thumb
            06.png
            06.png_thumb
            07.PNG
            07.PNG_thumb

            1 Reply Last reply Reply Quote 0
            • P Offline
              PbIXTOP
              last edited by

              @NiXeon:

              @NiXeon:

              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 на локальном интерфейсе. Если прокси работает в непрозрачном режиме никаких проблем с лимитером.

              1 Reply Last reply Reply Quote 0
              • N Offline
                NiXeon
                last edited by

                @PbIXTOP:

                Вы перепутали limiter с очередями. И проблема больше не со squid, а с правилами nat-rdr на локальном интерфейсе. Если прокси работает в непрозрачном режиме никаких проблем с лимитером.

                Не перепутал, а добавил очереди плюсом к лимитеру в правилах. Хотя проблема скорей всего в правилах на 3128-3129 порты. Прокси в прозрачном режиме. По-крайней мере речь про него здесь шла, как я понял

                1 Reply Last reply Reply Quote 0
                • werterW Offline
                  werter
                  last edited by

                  2 NiXeon
                  Scheduler type я бы выбрал faltq . HFSC некорректно работает в pf. А в дочерн. очередях исп. codelq.

                  1 Reply Last reply Reply Quote 0
                  • N Offline
                    NiXeon
                    last edited by

                    @werter:

                    2 NiXeon
                    Scheduler type я бы выбрал faltq . HFSC некорректно работает в pf. А в дочерн. очередях исп. codelq.

                    Вот как, спасибо. Подправил у себя. :) А для справки, как некорректно работает?

                    1 Reply Last reply Reply Quote 0
                    • werterW Offline
                      werter
                      last edited by

                      @NiXeon:

                      @werter:

                      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

                      1 Reply Last reply Reply Quote 0
                      • N Offline
                        NiXeon
                        last edited by

                        @werter:

                        В закладки
                        https://forum.pfsense.org/index.php?topic=111231.0
                        https://forum.pfsense.org/index.php?topic=110938.0

                        Спасибо!

                        1 Reply Last reply Reply Quote 0
                        • R Offline
                          randreevich
                          last edited by

                          PF 2.3.2 непонятно как при не работающем Limiters со сквидом (нужен прозрачный прокси) ограничить скорость юзерам в сети.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.