Pfsense 2.0 traffic shaper вопросы

dvserg

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

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

alexandrnew

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

dvserg

@alexandrnew:

спасибо
а по поводу шейпера на 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/

alexandrnew

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

dvserg

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

pf_packets_way.png_thumb

Michael Sh.

@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

dvserg

@Michael:

@dvserg:

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

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

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

Michael Sh.

@dvserg:

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

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

dvserg

@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.
Сам процесс шейпинга происходит при покидании пакетом роутера.
Заменил рисунок - пните если опять не то.

Michael Sh.

@dvserg:

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

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

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

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

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

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

dvserg

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

alexandrnew

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

dvserg

@alexandrnew:

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

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

alexandrnew

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

dvserg

@alexandrnew:

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

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

alexandrnew

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

Tamriel

Как так сделать чтоб исходящий тарфик HTTP (к примеру кто т upload ит фото на радикал) ходил по одной очереди
а остальной трафик HTTP ходил по другой ?

Это возможно ?

Вот что я сделал (но мне кажится что сёрфинг замедляется при этом :( )
m_Other HTTP inbound это для входящего трафика (закачки сёрфинг)
m_Other HTTP outbound для аплоада.

33.png_thumb

dvserg

Возможно, если настроите правилами файрвола.

Tamriel

Всё супер тока вот с фаерволом в шейпере как то трудновато.
можно ещё раз кто врубил какой принцип работы фаера

Как я понял
Абсолютно все общие правила должны быть вверху(тоесть если нада ловить p2p и прочий тяжёлый трафик)
а там http pop3 (всё что улаживается в небольшой диапозон портов и ip адрессов)
должны быть снизу с пометкой quick

alexandrnew

@Tamriel:

Всё супер тока вот с фаерволом в шейпере как то трудновато.
можно ещё раз кто врубил какой принцип работы фаера

Как я понял
Абсолютно все общие правила должны быть вверху(тоесть если нада ловить p2p и прочий тяжёлый трафик)
а там http pop3 (всё что улаживается в небольшой диапозон портов и ip адрессов)
должны быть снизу с пометкой quick

без quick
так как quick - сразу применяет правило, а не просто "метит" для шейпера, т.е. если вы сделаете quick, а в правилах на интерфейсе - запретите, то запрет не сработает.