Pfsense 2.0 traffic shaper вопросы
-
так и делаю, выше писал - реально скачивает в 8 мегабит, а показывает в 4 раза меньше
-
Попробуем разобраться с идеологией шейпера в 2.0
Первое, на что обращаем внимание - все правила файрвола с шейпингом помещаются в разделе Floating Firewall rules. Возможно это не обязательное условие, но все-таки для начала поступаем так-же.
так-с…
а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо? -
порядок в принципе какой? если очередь создалась на wan а я применяю на лан - или так нельзя?
-
Набросал некоторую информацию, которую нужно еще осмыслить.
-
а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо?
Floating Firewall rules - почти тоже, что и правила на интерфейсах, но с бОльшим функционалом (возможность выбора интерфейса (можно несколько), quick, направления in/out и т.п.) и при генерации правил pf располагаются "выше" правил на интерфейсах.
Соответственно если вы там например quick-запретите http, то до правил на интерфейсе дело не дойдёт.
В общем надо планировать куда и зачем помещать правила. Если я правильно понимаю задумку, то правила на интерфейсах предназначены для наглядного восприятия фильтрации входящего трафика на интерфейсе, а floating для более тонкой настройки, или назовём так, попыткой "таблезации" блокирующе/разрешающих правил pf.Для понимания работы шейпера и не только может помочь: http://homepage.mac.com/quension/pf/flow.png, хотя у меня остаётся ещё куча непонятых моментов.
-
-
а при этом как будет проходить правило? что такое Floating Firewall rules ? - меня интерисует - если я там разрешу например хттп для лан интерфейса, то в лан разрешать не надо?
Floating Firewall rules - почти тоже, что и правила на интерфейсах, но с бОльшим функционалом (возможность выбора интерфейса (можно несколько), quick, направления in/out и т.п.) и при генерации правил pf располагаются "выше" правил на интерфейсах.
Соответственно если вы там например quick-запретите http, то до правил на интерфейсе дело не дойдёт.
В общем надо планировать куда и зачем помещать правила. Если я правильно понимаю задумку, то правила на интерфейсах предназначены для наглядного восприятия фильтрации входящего трафика на интерфейсе, а floating для более тонкой настройки, или назовём так, попыткой "таблезации" блокирующе/разрешающих правил pf.Для понимания работы шейпера и не только может помочь: http://homepage.mac.com/quension/pf/flow.png, хотя у меня остаётся ещё куча непонятых моментов.
за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)
-
за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)
Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета. -
за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)
Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета.что терминология пфсенса - это я понял, хочу понять на каком этапе становятся правила (в теории они просто в списке правил идут раньше…)
по тегам - тоже логично, что после фаера. -
за картинку спасибо, но я не понял по ней в каком моменте Floating правила и где стоит шейпер… (в иптаблес тоже долго не понимал порядок прохождения пакетов)
Мне показалось, что я ответил, но наверно сумбурно выражаю мысли.
Floating - это терминология пфсенса - к PF прямого отношения не имеет. Генерируются "выше" "интерфейсных" по списку правил, а значит и срабатывают раньше.
Шейпер (ALTQ) встречается на картинке в 3 местах: два тэгирования - одно на входе, второе на выходе и очереди на выходе. Какое из тэгирований приоритетней не знаю, не проверял, но думаю последнее по прохождению пакета.что терминология пфсенса - это я понял, хочу понять на каком этапе становятся правила (в теории они просто в списке правил идут раньше…)
по тегам - тоже логично, что после фаера.Правила Floating Rules становятся до правил интерфейсов.
-
dvserg - я имел ввиду что pfctl покажет их до правил интерфейсов, правильно?
ничем другим они не отличаются (корме большей гибкости при настройке с гуя) -
dvserg - я имел ввиду что pfctl покажет их до правил интерфейсов, правильно?
ничем другим они не отличаются (корме большей гибкости при настройке с гуя)Именно так. См /tmp/rules.debug
Отличие в отсутствии интерфейса и опции quick по дефолту. По сути их можно трактовать как Пред-Правила, если рассматривать правила на интерфейсах, как основные. Если в Floating разрешить, например, ICMP с опцией quick, то этот трафик будет разрешен одновременно для всех интерфейсов. -
спасибо
а по поводу шейпера на 2.0 - порядок действий подскажете? -
спасибо
а по поводу шейпера на 2.0 - порядок действий подскажете?Готового нет
Вот http://forum.pfsense.org/index.php/topic,33731.msg175343.html#msg175343 информация к размышлению.Кому интересно мануалы по PF
http://dreamcatcher.ru/2010/01/10/%D0%9F%D0%B0%D0%BA%D0%B5%D1%82%D0%BD%D0%B0%D1%8F-%D1%84%D0%B8%D0%BB%D1%8C%D1%82%D1%80%D0%B0%D1%86%D0%B8%D1%8F-%D1%81-%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E-openbsd-pf/
http://dreamcatcher.ru/2009/12/24/%D0%9F%D0%B0%D0%BA%D0%B5%D1%82%D0%BD%D1%8B%D0%B9-%D1%84%D0%B8%D0%BB%D1%8C%D1%82%D1%80-openbsd-%D1%87%D0%B0%D1%81%D1%82%D1%8C-1/
http://dreamcatcher.ru/2009/12/28/pf-%D0%A7%D0%B0%D1%81%D1%82%D1%8C-2-%D0%A0%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F-%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3%D1%83%D1%80%D0%B0%D1%86%D0%B8%D1%8F/ -
ага!
я не видел что вы добавили пост.
ОГРОМНОЕ СПАСИБО! -
Схема прохождения трафика в PF (как я ее понял).
Здесь узлы NAT, Filter, Queue Tagging на конкретных интерфейсах показаны условно. На самом деле список правил один общий.
-
Набросал схему прохождения трафика в 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 -
Набросал схему прохождения трафика в PF (как я ее понял).
Не соответствует http://homepage.mac.com/quension/pf/flow.png. Главное несоответствие в контексте шейпера - очереди ALTQ работают на выходе из PF (т.е при выходе из очереди пакет уже никак не обрабатывается PF). Как я понимаю структуру пфсенса (во freebsd вариантов больше), с выхода очереди пакет попадает на IPFW (если необходимо) и далее на отправку транспортным протоколом интерфейса.
В контексте фильтра свойство in имеет пакет принятый роутером через этот интерфейс, а out - покидающий роутер через этот интерфейс. Акцентирую: принятый/покидающий роутер.In/Out применимы в контексте интерфейса, а не роутера. Пакет пришел на интерфейс (IN) и покинул его (Out). Далее системой роутится на другой интерфейс, на котором тоже пришел (In) / ушел (Out).
-
In/Out применимы в контексте интерфейса, а не роутера. Пакет пришел на интерфейс (IN) и покинул его (Out). Далее системой роутится на другой интерфейс, на котором тоже пришел (In) / ушел (Out).
Вот в этом и основной затык в понимании любых фильтров. Что значит "пакет покинул интерфейс"? Вот если вразумительно ответить себе на этот вопрос придёт и понимание.
-
Набросал схему прохождения трафика в 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.
Сам процесс шейпинга происходит при покидании пакетом роутера.
Заменил рисунок - пните если опять не то.