Navigation

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

    Деление канала почти по честному

    Russian
    3
    21
    12442
    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
      nmts last edited by

      Здравствуйте всем! Есть вопрос к знатокам. Ситуация следующая-имеется небольшая сеть 15 машин, интернет ADSL 2м\б и pfsense в качестве шлюза. Как сделать разделение канала на рабочие станции с гарантированной полосой пропускания - причём ширина полосы разная 128кб и 64кб. 5 машин на 128 и остальные 64. Всё только!!! через НАТ, регистрация Captive Portal.

      1 Reply Last reply Reply Quote 0
      • D
        dvserg last edited by

        @nmts:

        Здравствуйте всем! Есть вопрос к знатокам. Ситуация следующая-имеется небольшая сеть 15 машин, интернет ADSL 2м\б и pfsense в качестве шлюза. Как сделать разделение канала на рабочие станции с гарантированной полосой пропускания - причём ширина полосы разная 128кб и 64кб. 5 машин на 128 и остальные 64. Всё только!!! через НАТ, регистрация Captive Portal.

        Без использования прокси Squid делаем с помощью Traffic Shaper
        Создать 15(*2) очередей c нужными параметрами и прописать на каждую очередь нужный IP в правилах

        1 Reply Last reply Reply Quote 0
        • N
          nmts last edited by

          Спасибо dvserg !!! С очередями немного разобрался - делал так: через мастера создал правила в шейпере и правило для Penalty Box c IP адресом (пока одним, потом можно клонировать), потом поменял в нём приоритет и скорость(так правильно или нет?). Немножко почитал про очереди в Hfsc http://www.samag.ru/art/12.2004/12.2004_07.html может кому полезно будет. Возник вопрос, а можно ли в правило вставить диапазон адресов? Допустим одно правило для 192.168.0.15 по 192.168.0.25 и другое для 192.168.0.30-35? Тоесть не создавать 15 правил а два.

          ToXaNSK Squid у меня на Ubuntu установлен был, вместе с SAMS - гемору было… но работало!!! Сейчас Squid с Lightsquid в pfsense выполняют роль лёгкого контроля за юзерами по http(кто?куда?когда?)? А условия требуют полного контроля над полосами пропускания по всем портам и протоколам  :o да и самому очень интересно разобратся во всей этой кухне.

          1 Reply Last reply Reply Quote 0
          • D
            dvserg last edited by

            Дело в том, что каждая очередь есть канал, а каждое правило загоняет указанные IP в одну указанную очередь. Если делать диапазон в правиле, то все хосты из указанного диапазона будут делить одну очередь/полосу между собой

            1 Reply Last reply Reply Quote 0
            • N
              nmts last edited by

              А имеет ли какое нибудь значение место правила в очереди? Вверху оно находится, внизу и.т.д???

              1 Reply Last reply Reply Quote 0
              • D
                dvserg last edited by

                @nmts:

                А имеет ли какое нибудь значение место правила в очереди? Вверху оно находится, внизу и.т.д???

                Эээ Срабатывает первое подходящее правило по списку, поэтому важно быть уверенным, что какое-либо вышестоящее правило не перекроет ваше. И еще - ДНС и ICMP загоните в очередь с высоким приортетом - ширина очереди 1-3% от ширины канала

                1 Reply Last reply Reply Quote 0
                • R
                  r3l4x last edited by

                  Ну про DNS ясно, а зачем ICMP загонять в очередь с высоким приоритетом?

                  1 Reply Last reply Reply Quote 0
                  • D
                    dvserg last edited by

                    @r3l4x:

                    Ну про DNS ясно, а зачем ICMP загонять в очередь с высоким приоритетом?

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

                    1 Reply Last reply Reply Quote 0
                    • N
                      nmts last edited by

                      Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум.  ???

                      1 Reply Last reply Reply Quote 0
                      • D
                        dvserg last edited by

                        @nmts:

                        Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум.  ???

                        Смотри Firewall Rules - там есть такая опция ' количество подключений-сессий с одного IP адреса'.
                        Но опять-же, это если вы не используете сквид как прокси. А в сквиде есть свой шейпер per/IP и тротлинг указанных расширений(то есть ограничение скорости закачек для определенных типов файлов)

                        1 Reply Last reply Reply Quote 0
                        • R
                          r3l4x last edited by

                          @nmts:

                          Спасибо за ответы! А как можно ограничить количество подключений-сессий с одного IP адреса? (чтоб исключить многопоточные закачки). Вобщем веб серфинг на максимальной скорости а закачки по http и ftp минимум.  ???

                          Колличество сессий ограничить довольно просто, если используешь веб-конфигуратор, то go to Firewall > Rules. Нажми "edit rule" для интересующего тебя разрешающего правила, далее "Advanced Options", там всплывет несколько настроек:
                          Simultaneous client connection limit - ограничивает количество соединений с одного IP-адреса.
                          Maximum state entries per host - Максимальное количество записей в таблице состояний созданных данным правилом (опять же per ip)
                          Maximum new connections / per second - колличество новых соединений в одну секнду.
                          State Timeout in seconds  - Время, через которое запись в таблице состояний удаляется, если передача данных м-у двумя узлами закончена, например TIME_WAIT:TIME_WAIT или CLOSING:ESTABLISHED.

                          А вот со вторым правилом все немного сложнее, тут нужен шейпинг, iptables с наложенным patch-o-matic это умеет, а вот pf+altq наверно нет, хотя…

                          1 Reply Last reply Reply Quote 0
                          • N
                            nmts last edited by

                            Даааа… Чем больше узнаёшь тем меньше знаеш  :-\ . Ну а какие нибудь усреднённые значения для ограничения сессий есть(сколько с одного адреса, и. т. д.)? Или может какой нибудь мануал на эту тему (желательно мануал, что не тупо скопировать, а разобратся  ;D)

                            1 Reply Last reply Reply Quote 0
                            • D
                              dvserg last edited by

                              @nmts:

                              Даааа… Чем больше узнаёшь тем меньше знаеш  :-\ . Ну а какие нибудь усреднённые значения для ограничения сессий есть(сколько с одного адреса, и. т. д.)? Или может какой нибудь мануал на эту тему (желательно мануал, что не тупо скопировать, а разобратся  ;D)

                              А что не понятного? Делаешь на лане правило разрешения
                              LAN | TCP | LanIP:anyPORT > anyIP:80
                              и указываешь, например,
                              Simultaneous client connection limit = 10

                              1 Reply Last reply Reply Quote 0
                              • N
                                nmts last edited by

                                Да в принципе понятно. Только какая именно разница будет между 10 и допустим 100 сессиями? (как они вобще на канал влияют). В Traffic Inspector выставлял и 50 и 10 и 500 сессий особых различий не заметил.

                                1 Reply Last reply Reply Quote 0
                                • R
                                  r3l4x last edited by

                                  @nmts:

                                  Да в принципе понятно. Только какая именно разница будет между 10 и допустим 100 сессиями? (как они вобще на канал влияют). В Traffic Inspector выставлял и 50 и 10 и 500 сессий особых различий не заметил.

                                  Ну тут ты не прав, у меня на шлюзе внешний канал 1 gb/s, некоторые юзверы умудряются тянуть с торрента аж в 20000 потоков ) Я первый раз увидел, у меня чуть глаз не выпал ) Так что тут хочешь не хочешь, приходится ограничивать колличество сессий.
                                  Да и на TI это нормально работает, сам проверял. Т.е. ставишь 100 соединений пер ип, запускаешь торрент, открывешь несколько вкладок в браузере, и все, сервер блокирует все новые попытки соедениться.

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    nmts last edited by

                                    Ну а для нормального веб серфинга сколько сессий рекомендуется разрешить?

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      r3l4x last edited by

                                      Да мне кажется ты не туда смотришь, т.е. твоя цель в чем? Поровну поделить канал между пользователями, т.е. если wan=512 кбит/c, если лезет один пользователь, отдать ему 512, если 2, то поделить поровну (256 + 256), и не важно сколько у них сессий, 100 у первого и одна у второго.
                                      Если так, то Pf+altq тебе не поможет.

                                      А вообще смотри сам, скажем для серфинга 30 сессий за глаза, лично для меня. А лучше всего эксперементируй и слушай отзывы потребителей, так найдешь золотую середину.

                                      1 Reply Last reply Reply Quote 0
                                      • N
                                        nmts last edited by

                                        Нашёл: 1)TCP-сессия - это соединение, которое устанавливается с Вашим провайдером при попытке доступа к какому-либо объекту в Интернет. Например, при открытии браузером некоторой странички, будут открыты сессии, во-первых, для выкачивания структуры страницы, во-вторых для выкачивания всех объектов, находящихся на этой страничке (рисунки, скрипты, приложения, java-апплеты и т.д.). Однако, из-за малого размера каждого объекта, сессии в данном случае будут быстротечны, поэтому даже для открытия странички, очень загруженной различными обектами, достаточно 3 - 5 сессий. Действительно при открытии нескольких окон браузера существует вероятность занятия всего лимита сессий, однако данная ситуация весьма кратковременна, и не особо заметна. Другое дело, если Вы выкачиваете файл. В данном случае сессия занята длительное время (столько, сколько нужно, чтобы выкачать файл). Количество сессий соответствует числу выкачиваемых файлов, вот здесь и существует опасность занятия всего канала. Теперь более менее понятно куда копать  ;D

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          r3l4x last edited by

                                          Молодцом! Но теме "Деление канала почти по честному" не соответствует.  :)

                                          1 Reply Last reply Reply Quote 0
                                          • N
                                            nmts last edited by

                                            Ну и последний вопрос по приоритетам - какой выше 0 или 7 ?

                                            1 Reply Last reply Reply Quote 0
                                            • R
                                              r3l4x last edited by

                                              0 - min
                                              7 - max

                                              1 Reply Last reply Reply Quote 0
                                              • First post
                                                Last post

                                              Products

                                              • Platform Overview
                                              • TNSR
                                              • pfSense Plus
                                              • Appliances

                                              Services

                                              • Training
                                              • Professional Services

                                              Support

                                              • Subscription Plans
                                              • Contact Support
                                              • Product Lifecycle
                                              • Documentation

                                              News

                                              • Media Coverage
                                              • Press
                                              • Events

                                              Resources

                                              • Blog
                                              • FAQ
                                              • Find a Partner
                                              • Resource Library
                                              • Security Information

                                              Company

                                              • About Us
                                              • Careers
                                              • Partners
                                              • Contact Us
                                              • Legal
                                              Our Mission

                                              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                              Subscribe to our Newsletter

                                              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                              © 2021 Rubicon Communications, LLC | Privacy Policy