Pfsense 2.0 traffic shaper вопросы



  • народ, выручайте, видимо туплю,
    настраиваю шейпер мастером, выставляю для трафа р2р 1 мегабит лимит - не помогает, трафик ходит по полной..
    лазил по форуму, насколько понял в 2.0 логика настройки шейпера сменилась?
    надо правила для очередей в файрволе создавать?
    может кто how-to подскажет по шейперу пфсенса 2.0 ? по шагам, как пример



  • создаю мастером, p2p поток появляется в закладке wan default



  • помогите плиз… очень надо шейпер, задача сделать высокий приоритет, с резервированием каналов:
    трафик \ приоритет \ минимальная ширина канала
    рдп \высокий \ 1 мегабит
    опенвпн \ высокий \2 мегабита
    хттп или хттпс \  стандартный \ 0,5 мегабита
    смб \ стандартный \ 0,5 мегабита
    р2р \ минимальный \ 100 кбит
    вопрос как?



  • в фаерволе указываешь правила по которым будет ходить трафик в этих трубах.



  • в lan \wan правилах?
    Ackqueue/Queue - я так понимаю Ackqueue - труба для установления соединений /Queue  -собственно очередь?
    для р2р трафика - его как определять? layer 7 использовать?



  • опять таки, мастером сделал очереди,
    в очередях
      qDefault on WAN  174.82Kb/s
    другие пусты. при этом идет закачка по хттп в 8 мегабит…
    как понимать?



  • @alexandrnew:

    опять таки, мастером сделал очереди,
    в очередях
       qDefault on WAN    174.82Kb/s
    другие пусты. при этом идет закачка по хттп в 8 мегабит…
    как понимать?

    Правило не поймало пакет и не переправило в нужную очередь. Работает дефолтная очередь.



  • правила только пробую настроить, не пойму почему разница в скорости почти в 4ре раза…



  • @alexandrnew:

    правила только пробую настроить, не пойму почему разница в скорости почти в 4ре раза…

    Мегабайт Мегабиту рознь. Какая скорость канала и что выставлено в родительских очередях? Должно быть чуть меньше чем скорость канала, в том числе с учетом симметрии (АДСЛ к примеру).



  • на wan Bandwidth = 8Mbit
    там оптика…в реале дает около 8,5 мегабит..
    очередя должны біть на lan или wan? так как wan 2 интерфейса (траф пока ходит по одному, роутинг не настраивал) - делал правала мастером Single Lan multi Wan
    не могу понять что далее надо делать?



  • Применительно к 1.2 см qWanRoot/qLanRoot там без привязки к интерфейсу..
    Версии 2.0 под рукой нет пока.



  • всегда проверяй работу шейпера по статусу очередей.





  • так и делаю, выше писал - реально скачивает в 8 мегабит, а показывает в 4 раза меньше



  • @dvserg:

    Попробуем разобраться с идеологией шейпера в 2.0

    Первое, на что обращаем внимание - все правила файрвола с шейпингом помещаются в разделе Floating Firewall rules. Возможно это не обязательное условие, но все-таки для начала поступаем так-же.

    так-с…
    а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо?



  • порядок в принципе какой? если очередь создалась на wan а я применяю на лан - или так нельзя?



  • Набросал некоторую информацию, которую нужно еще осмыслить.



  • @alexandrnew:

    а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо?

    Floating Firewall rules - почти тоже, что и правила на интерфейсах, но с бОльшим функционалом (возможность выбора интерфейса (можно несколько), quick, направления in/out и т.п.) и при генерации правил pf располагаются "выше" правил на интерфейсах.
    Соответственно если вы там например quick-запретите http, то до правил на интерфейсе дело не дойдёт.
    В общем надо планировать куда и зачем помещать правила. Если я правильно понимаю задумку, то правила на интерфейсах предназначены для наглядного восприятия фильтрации входящего трафика на интерфейсе, а floating для более тонкой настройки, или назовём так, попыткой "таблезации" блокирующе/разрешающих правил pf.

    Для понимания работы шейпера и не только может помочь: http://homepage.mac.com/quension/pf/flow.png, хотя у меня остаётся ещё куча непонятых моментов.



  • @dvserg:

    Набросал некоторую информацию, которую нужно еще осмыслить.

    а где и что набросали?



  • @Michael:

    @alexandrnew:

    а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо?

    Floating Firewall rules - почти тоже, что и правила на интерфейсах, но с бОльшим функционалом (возможность выбора интерфейса (можно несколько), quick, направления in/out и т.п.) и при генерации правил pf располагаются "выше" правил на интерфейсах.
    Соответственно если вы там например quick-запретите http, то до правил на интерфейсе дело не дойдёт.
    В общем надо планировать куда и зачем помещать правила. Если я правильно понимаю задумку, то правила на интерфейсах предназначены для наглядного восприятия фильтрации входящего трафика на интерфейсе, а floating для более тонкой настройки, или назовём так, попыткой "таблезации" блокирующе/разрешающих правил pf.

    Для понимания работы шейпера и не только может помочь: http://homepage.mac.com/quension/pf/flow.png, хотя у меня остаётся ещё куча непонятых моментов.

    за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)



  • @alexandrnew:

    за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)

    Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
    Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
    Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета.



  • @Michael:

    @alexandrnew:

    за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)

    Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
    Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
    Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета.

    что терминология пфсенса - это я понял, хочу понять на каком этапе становятся правила (в теории они просто в списке правил идут раньше…)
    по тегам - тоже логично, что после фаера.



  • @alexandrnew:

    @Michael:

    @alexandrnew:

    за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)

    Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
    Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
    Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета.

    что терминология пфсенса - это я понял, хочу понять на каком этапе становятся правила (в теории они просто в списке правил идут раньше…)
    по тегам - тоже логично, что после фаера.

    Правила Floating Rules становятся до правил интерфейсов.



  • dvserg - я имел ввиду что  pfctl  покажет их до правил интерфейсов, правильно?
    ничем другим они не отличаются (корме большей гибкости при настройке с гуя)



  • @alexandrnew:

    dvserg - я имел ввиду что  pfctl  покажет их до правил интерфейсов, правильно?
    ничем другим они не отличаются (корме большей гибкости при настройке с гуя)

    Именно так. См /tmp/rules.debug
    Отличие в отсутствии интерфейса и опции quick по дефолту. По сути их можно трактовать как Пред-Правила, если рассматривать правила на интерфейсах, как основные. Если в Floating разрешить, например, ICMP с опцией quick, то этот трафик будет разрешен одновременно для всех интерфейсов.



  • спасибо
    а по поводу шейпера на 2.0 - порядок действий подскажете?



  • @alexandrnew:

    спасибо
    а по поводу шейпера на 2.0 - порядок действий подскажете?

    Готового нет
    Вот http://forum.pfsense.org/index.php/topic,33731.msg175343.html#msg175343 информация к размышлению.

    Кому интересно мануалы по PF
    http://dreamcatcher.ru/2010/01/10/Пакетная-фильтрация-с-помощью-openbsd-pf/
    http://dreamcatcher.ru/2009/12/24/Пакетный-фильтр-openbsd-часть-1/
    http://dreamcatcher.ru/2009/12/28/pf-Часть-2-Расширенная-конфигурация/



  • ага!
    я не видел что вы добавили пост.
    ОГРОМНОЕ СПАСИБО!



  • Схема прохождения трафика в PF (как я ее понял).
    Здесь узлы NAT, Filter, Queue Tagging на конкретных интерфейсах показаны условно. На самом деле список правил один общий.




  • @dvserg:

    Набросал схему прохождения трафика в PF (как я ее понял).

    Не соответствует http://homepage.mac.com/quension/pf/flow.png. Главное несоответствие в контексте шейпера - очереди ALTQ работают на выходе из PF (т.е при выходе из очереди пакет уже никак не обрабатывается PF). Как я понимаю структуру пфсенса (во freebsd вариантов больше), с выхода очереди пакет попадает на IPFW (если необходимо) и далее на отправку транспортным протоколом интерфейса.
    В контексте фильтра свойство in имеет пакет принятый роутером через этот интерфейс, а out - покидающий роутер через этот интерфейс. Акцентирую: принятый/покидающий роутер.

    По-моему путь пакета сквозь роутер на картинке упрощённо должен выглядеть так:
    int LAN -> in filter -> processing -> out filter -> shaper queue -> int WAN



  • @Michael:

    @dvserg:

    Набросал схему прохождения трафика в PF (как я ее понял).

    Не соответствует http://homepage.mac.com/quension/pf/flow.png. Главное несоответствие в контексте шейпера - очереди ALTQ работают на выходе из PF (т.е при выходе из очереди пакет уже никак не обрабатывается PF). Как я понимаю структуру пфсенса (во freebsd вариантов больше), с выхода очереди пакет попадает на IPFW (если необходимо) и далее на отправку транспортным протоколом интерфейса.
    В контексте фильтра свойство in имеет пакет принятый роутером через этот интерфейс, а out - покидающий роутер через этот интерфейс. Акцентирую: принятый/покидающий роутер.

    In/Out применимы в контексте интерфейса, а не роутера. Пакет пришел на интерфейс (IN) и покинул его (Out). Далее системой роутится на другой интерфейс, на котором тоже пришел (In) / ушел (Out).



  • @dvserg:

    In/Out применимы в контексте интерфейса, а не роутера. Пакет пришел на интерфейс (IN) и покинул его (Out). Далее системой роутится на другой интерфейс, на котором тоже пришел (In) / ушел (Out).

    Вот в этом и основной затык в понимании любых фильтров. Что значит "пакет покинул интерфейс"? Вот если вразумительно ответить себе на этот вопрос придёт и понимание.



  • @Michael:

    @dvserg:

    Набросал схему прохождения трафика в PF (как я ее понял).

    Не соответствует http://homepage.mac.com/quension/pf/flow.png. Главное несоответствие в контексте шейпера - очереди ALTQ работают на выходе из PF (т.е при выходе из очереди пакет уже никак не обрабатывается PF). Как я понимаю структуру пфсенса (во freebsd вариантов больше), с выхода очереди пакет попадает на IPFW (если необходимо) и далее на отправку транспортным протоколом интерфейса.
    В контексте фильтра свойство in имеет пакет принятый роутером через этот интерфейс, а out - покидающий роутер через этот интерфейс. Акцентирую: принятый/покидающий роутер.

    По-моему путь пакета сквозь роутер на картинке упрощённо должен выглядеть так:
    int LAN -> in filter -> processing -> out filter -> shaper queue -> int WAN

    Мммм примерно понял нестыковку: Queue tagging - есть "маркировка" пакетов для ALTQ.
    Сам процесс шейпинга происходит при покидании пакетом роутера.
    Заменил рисунок - пните если опять не то.



  • @dvserg:

    Заменил рисунок - пните если опять не то.

    Да вот тоже затрудняюсь сказать на сколько можно упросить картинку, отражающую логику прохождения пакета, чтобы не потерять достоверность и ещё больше не запутать потенциального изучающего.
    Мне кажется важным указывать на картинке контекст в котором рассматривается путь прохождения пакета. Ведь если рассматривать PF в целом, то из исходной картинки вообще ничего не выкинуть. А если рассматривать шейпер PfSense, то придётся добавлять обработку Layer7, которая осуществляется не с помощью нативных средств PF.

    Мне представляется важным:

    • Показ некоторой обработки пакета, например в виде "облака", даже если эта обработка не важна в рассматриваемом контексте. Как пример - маршрутизация в контексте шейпера, дабы не создавалось впечатление прямой кишки.
    • "Пути", которые проходит пакет при приёме и передаче логически разные. Неплохо бы это подчёркивать на схеме.
    • Очереди ALTQ на разных интерфейсах независимы. Изображение ALTQ одним блоком может вызвать ощущение корреляции между очередями на разных интерфейсах.

    Я вот думаю неплохо бы попытаться изобразить полную схему обработки трафика Пфсенсом, да что-то пока стрёмно. Туда ведь и IPv6 надо добавлять и протоколы маршрутизации.

    PS (offtop):
    Пробовал тут накатить IPv6 ветку на домашний пфсенс. У меня провайдер даёт нативную поддержку IPv6. Пока ничего хорошего не получилось.



  • У меня стояла задача блоками изобразить простую логику обработки пакета, чтобы было видно и понятно когда и какой этап проходит. Более продвинутым и оригинальная схема поможет. ALTQ отображена как функциональный блок без внутренней детализации - здесь еще есть вариант подумать над ней.



  • да я в принципе и так понял :) недавно разбирался с iptables…
    думаю по топикам моим видно что не совсем начинающий :) но всего знать не возможно...
    как сказал у меня знакомый - если человек умеет фаер нормально писать с консоли - то особых проблем в понимании нету :)



  • @alexandrnew:

    да я в принципе и так понял :) недавно разбирался с iptables…
    думаю по топикам моим видно что не совсем начинающий :) но всего знать не возможно...
    как сказал у меня знакомый - если человек умеет фаер нормально писать с консоли - то особых проблем в понимании нету :)

    Ну ты понял, а другие? Хочется чтобы раз взглянул и понял саму идею, а не лазить днями по первоисточникам и искать смысл.



  • я ж не спорю :)
    да и нет уверенности что на 100% понял :)



  • @alexandrnew:

    я ж не спорю :)
    да и нет уверенности что на 100% понял :)

    Там кстати неточности и неправильности. Создан отдельный топик - по мере понимания кладу все туда. Если есть комменты/замечания, в личку или сюда.



  • топик видел, спасибо
    я подписался :) и заглядываю периодически.
    пока пригрузили работой, посему - только читаю и думаю.тестить буду со вторника..
    с наступающими! и Вам желаю отдохнуть!


Locked