Jump to content
Калькуляторы
Использование PF у провайдеров  

143 members have voted

  1. 1. Как Вы используете PF ?

    • Как фаервол
      44
    • Как Шейпер
      3
    • Как фаервол и шейпер
      21
    • не юзаю я это чудо :)
      75


Шейпинг провайдера на PF Шейпинг провайдера на PF, реально ли это ?

В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 1500+ абонентам на разные скорости и по разным направлениям.

На данный момент нарезкой занимается ipfw, но хочется это переделать на PF. Появилось пару вопросов :

1. Насколько грамотно умеет PF нарезать канал ?

2. Как он себя ведет под большой нагрузкой ?

3. Использует ли его вообще кто-то для шейпинга на провайдерах ? (если можно хоть короткий пример его использования в этом качестве)

4. Насколько компактным получается фаервол . Можно ли как в ipfw запихать несколько сот абонов в один пайп, чтоб каждому нарезалась конкретная полоса?

 

 

Так пару мелких вопросов:

1. Как можно в одном правиле указать несколько портов ? (Через запятую, как в ipfw Не работает. Если ставить в {} то разбивает на два отдельных правила, чего очень не хотелось бы)

2. В ipfw можно сделать , чтоб в одной таблице были ip или сети c разными ключами. А можно ли такое сделать в PF ?

Пример вышесказанного

europe# ipfw table 7 list |more
172.16.10.25/32 22
172.16.10.27/32 41
172.17.1.3/32 41
172.17.1.5/32 22
172.17.1.6/32 22
172.17.5.3/32 41
172.17.6.6/32 30
172.17.6.8/32 30
...

Share this post


Link to post
Share on other sites

На pf/altq провайдерский шейпер сделать теоретически можно, но на практике это будет неэффективное решение. Во-первых, в pf/altq нет эффективного классификатора, аналогичного pipe tablearg или динамическим пайпам в dummynet, u32 или flow в Linux. На каждый IP-адрес нужно вводить по 2 правила файрвола, и для нескольких тысяч адресов это будет жутко тормозить. Во-вторых, правила нельзя редактировать из командной строки по одному, они все загружаются из файла pf.conf. Опять же, это будет дикий тормоз при тысячах аккаунтов. Плюс к этому, в ALTQ до сих пор не устранены giant locks.

Share this post


Link to post
Share on other sites

+1, дамминет наше все)

проще наверное с pf функции перенести на ipfw и избавится от него.

Share this post


Link to post
Share on other sites

Ну я не говорю, что pf совсем не нужен. На бордере для NAT или для какой-то приоритезации трафика он вполне сгодится, но только не в качестве шейпера.

Share this post


Link to post
Share on other sites

Не вижу в опросе варианта ответа "как НАТ"

Share this post


Link to post
Share on other sites

pf - как фаер и нат

ng_car - шейпер.

очень довольны.

Share this post


Link to post
Share on other sites

Да, НАТ упустил из вида.

PF с натом справляется очень хорошо, думаю его многие юзают именно в этом контексте.

 

Насчет ng_car, можно подробнее ?

1. его +/- по сравнению с пайпами

2. Как изменилась загрузка ЦПУ при его использовании ?

3. Сколько абонов он шейпит на одном компе ?

4. Насколько точно это происходит ?

5. Насколько он быстро отрабатывает по сравнению с обычными пайпами ?

6. Возникали ли с ним какие-то проблемы, какие неудобства и недостатки у него ?

 

Share this post


Link to post
Share on other sites
Ну я не говорю, что pf совсем не нужен. На бордере для NAT

а кто сказал что в ipfw нельзя натить?

Share this post


Link to post
Share on other sites

если это было про Ipfw nat, то для дома мож и можно, а для провайдера - ну его подальше. Если про ngnat, то его дешевле будет использовать вместе с mpd, а тут уже фаервол ну никак не пришьешь.

Share this post


Link to post
Share on other sites

ПФ как бы не заточен под динамический шейпинг.

Те во всей документации которую я перечитал примеров именно для такого я не видел.

 

 

3. Я соседку им шейплю :)

Пример нужен?)

 

4. Вероятно.

Нужно углублятся в синтаксис, там где про якоря и разметку пакетов.

Обычно все пользуются в dumb режиме: нат и пара простых правил.

 

 

 

1. tcp_services_to_inet="{ 21, 22, 25, 43, 53, 80, 110, 443, 465, 995, 1024:65535 }" # internet tcp services

Всё, кроме последнего станет раздельными правилами после применения.

 

2. table <private_nets> const { 10.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }

table <deny_hosts> persist file "/etc/pf.deny"

где pf.deny:

210.82.0.0/15 #2008.12 - China Network Communications Group Corporation

221.0.0.0/15 #2008.12 - CNC Group CHINA169 Shandong Province Network

91.205.111.53/32 #2009.02 - United Kingdom UKNETCOM Ltd

194.8.74.0/23 #2009.06 - spam to my non existent forum

 

Share this post


Link to post
Share on other sites

читайте не по диагонали. Я там тоже про natd ничего не сказал.

Share this post


Link to post
Share on other sites
ПФ как бы не заточен под динамический шейпинг.

Те во всей документации которую я перечитал примеров именно для такого я не видел.

 

 

3. Я соседку им шейплю :)

Пример нужен?)

 

4. Вероятно.

Нужно углублятся в синтаксис, там где про якоря и разметку пакетов.

Обычно все пользуются в dumb режиме: нат и пара простых правил.

 

 

 

1. tcp_services_to_inet="{ 21, 22, 25, 43, 53, 80, 110, 443, 465, 995, 1024:65535 }" # internet tcp services

Всё, кроме последнего станет раздельными правилами после применения.

 

2. table <private_nets> const { 10.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 }

table <deny_hosts> persist file "/etc/pf.deny"

где pf.deny:

210.82.0.0/15 #2008.12 - China Network Communications Group Corporation

221.0.0.0/15 #2008.12 - CNC Group CHINA169 Shandong Province Network

91.205.111.53/32 #2009.02 - United Kingdom UKNETCOM Ltd

194.8.74.0/23 #2009.06 - spam to my non existent forum

Понятно, значит шейпинг в ПФ для провайдера абсолютно не интересен, ввиду его убогости :( .

 

 

1. А нельзя это же сделать, но чтоб Не было разбития на N правил (не рационально это как-то..)?

2. Это стандартное использование таблиц. Я имел ввиду, чтоб например в таблице deny_hosts были ключи. И при использовании например такого выражения <deny_hosts:10> в правилах, этому выражению соответствовали только те записи, которые имеют ключ 10.

Существует что-то подобное в ПФ?

Share this post


Link to post
Share on other sites

Может и интересен, копать нужно. Никто не копает или не выкладывает.

 

1. Нет.

Полагаю и внутри ipfw правила также множатся, просто вы этого не видите.

Вообщем исходники есть, изучайте :)

 

2. Честно говоря не понял вопроса.

Сделайте кучу таблиц, каждая будет вместо ключа. В чём смысл?

Share this post


Link to post
Share on other sites
Может и интересен, копать нужно. Никто не копает или не выкладывает.

 

1. Нет.

Полагаю и внутри ipfw правила также множатся, просто вы этого не видите.

Вообщем исходники есть, изучайте :)

В том и дело, что нужно не просто копать, а серьезно дорабатывать pf и ALTQ под эту задачу. Для шейпинга необходимо создавать много очередей и хэшировать их номера по IP-адресам, тогда время поиска нужной очереди для каждого пакета не будет зависеть от числа IP. В dummynet и Linux такой функционал есть, а в pf/ALTQ -- нет. Все очереди и правила классификации нужно описывать явно, хэширования нет, поэтому каждый пакет будет проходить через тысячи правил, прежде чем попасть в свою очередь. Вызывать dummynet из pf тоже не выход. Шейпер должен уметь редактировать правила по одному, иначе для внесения одного изменения, например когда пользователь переключен на другой тариф или заблокирован, придется перезагружать весь огромный ruleset. Не уверен в том, что этот патч поддерживает создание динамических пайпов на основе таблиц pf. Если это есть, тогда можно редактировать таблицы из командной строки с помощью pfctl и сделать юзабельный шейпер.
Edited by photon

Share this post


Link to post
Share on other sites

authpf - там описывается примерно то что автор искал: каждому клиенту свои правила, динамично.

 

 

photon -

Это уж как организуете правила.

Существующие соединения не проходят правила. ПФ в начале по таблице состояний ищет, если там нет - по правилам прогоняет и создаёт запись в таблице состояний.

В ipfw можно тоже очень неоптимально всё написать.

Share this post


Link to post
Share on other sites
Это уж как организуете правила.

Существующие соединения не проходят правила. ПФ в начале по таблице состояний ищет, если там нет - по правилам прогоняет и создаёт запись в таблице состояний.

В ipfw можно тоже очень неоптимально всё написать.

Вы не понимаете о чем я говорю. Очереди ALTQ -- это не state, а stateful inspection не имеет отношения к классификации пакетов. Даже если он и умеет на основе стейтов ставить пакеты в очереди, то все равно получится неоптимально, т.к. таблица стейтов быстро меняется. Довольно много трафика приходится на протоколы без состояний (ICMP, UDP), для которых стейты избыточны. В dummynet и Linux IP-адрес можно использовать как ключ хэша вида IP => class id или как аргумент функции, делающей преобразование вида IP -> class id (или pipe number в терминологии dummynet). В этом случае время классификации не зависит от числа IP и происходит за некоторое постоянное время. В pf/ALTQ аналогичного функционала нет, в этом и проблема.
Edited by photon

Share this post


Link to post
Share on other sites
В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 1500+ абонентам на разные скорости и по разным направлениям.

На данный момент нарезкой занимается ipfw, но хочется это переделать на PF. Появилось пару вопросов :

1. Насколько грамотно умеет PF нарезать канал ?

2. Как он себя ведет под большой нагрузкой ?

3. Использует ли его вообще кто-то для шейпинга на провайдерах ? (если можно хоть короткий пример его использования в этом качестве)

4. Насколько компактным получается фаервол . Можно ли как в ipfw запихать несколько сот абонов в один пайп, чтоб каждому нарезалась конкретная полоса?

я описывал не так давно как работала у нас дисциплина hfsc:

http://forum.nag.ru/forum/index.php?showto...rt=#entry394651

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

был самописный измеритель скорости по каждой очереди и рисовал в реальном времени какой приоритет сколько отжирает

Share this post


Link to post
Share on other sites

О! это уже очень интересно!! Спасибо за ссылку !

Share this post


Link to post
Share on other sites
я описывал не так давно как работала у нас дисциплина hfsc

Гм... это работало с 25 Мбитным аплинком и с 150-250 юзерами? С такой нагрузкой даже ALTQ справится. А вот 500 Мбит и более 4000 юзеров, которые уверенно держит FreeBSD с dummynet -- это совсем другое дело.

Edited by photon

Share this post


Link to post
Share on other sites

Добавлю свои пять копеек. :-) В свое время тоже повелся на pf (как же - написанный с нуля файрволл от команды OpenBSD!), однако отсутствие динамических пайпов по маскам не позволяло использовать его как шейпер - был pf на файрволл и нат и dummynet на шейп. В итоге с увеличением количества юзеров и полосы (3500+ и около 200-250 Мбит) все начало конкретно тормозить, что выливалось в потерю пакетиков. Сделал профилирование через hwpmc (кто не в курсе - http://wiki.freebsd.org/PmcTools) чего, кстати, желаю и всем остальным, кто хочет поближе узнать, чем занят комп в то время, которое в top'е обозначается как interrupt и т.п. :-) Так вот, в итоге выяснилось, что nat от pf - это такая жручая штука, что лучше потратить время и сделать адекватный набор правил для ipfw, чем насиловать систему этим pf.... Более подробно я писал об этом в этой теме - http://forum.nag.ru/forum/index.php?showtopic=47497

В итоге на основе личного опыта могу сказать, что pf - это действительно быстрый и удобный (пару строчек написать!) способ ненапряжно отфайрволлить/отнатить/зашейпить, например, офис. Или квартиру. Но для серьезной провайдерской работы он не годится принципиально. :-) ipfw - наше все! И с годами становится все лучше и лучше...

Share this post


Link to post
Share on other sites

аминь!

 

Share this post


Link to post
Share on other sites

NAT жручий независимо от того, в pf он или нет. У меня pf nat работает пять лет.

Share this post


Link to post
Share on other sites
В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 1500+ абонентам на разные скорости и по разным направлениям.

На данный момент нарезкой занимается ipfw, но хочется это переделать на PF. Появилось пару вопросов :

1. Насколько грамотно умеет PF нарезать канал ?

2. Как он себя ведет под большой нагрузкой ?

3. Использует ли его вообще кто-то для шейпинга на провайдерах ? (если можно хоть короткий пример его использования в этом качестве)

4. Насколько компактным получается фаервол . Можно ли как в ipfw запихать несколько сот абонов в один пайп, чтоб каждому нарезалась конкретная полоса?

я описывал не так давно как работала у нас дисциплина hfsc:

http://forum.nag.ru/forum/index.php?showto...rt=#entry394651

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

был самописный измеритель скорости по каждой очереди и рисовал в реальном времени какой приоритет сколько отжирает

Можете более подробно описать как вы это делали на hfsc с примерами конфигов ?

 

Добавлю свои пять копеек. :-) В свое время тоже повелся на pf (как же - написанный с нуля файрволл от команды OpenBSD!), однако отсутствие динамических пайпов по маскам не позволяло использовать его как шейпер - был pf на файрволл и нат и dummynet на шейп. В итоге с увеличением количества юзеров и полосы (3500+ и около 200-250 Мбит) все начало конкретно тормозить, что выливалось в потерю пакетиков. Сделал профилирование через hwpmc (кто не в курсе - http://wiki.freebsd.org/PmcTools) чего, кстати, желаю и всем остальным, кто хочет поближе узнать, чем занят комп в то время, которое в top'е обозначается как interrupt и т.п. :-) Так вот, в итоге выяснилось, что nat от pf - это такая жручая штука, что лучше потратить время и сделать адекватный набор правил для ipfw, чем насиловать систему этим pf.... Более подробно я писал об этом в этой теме - http://forum.nag.ru/forum/index.php?showtopic=47497

В итоге на основе личного опыта могу сказать, что pf - это действительно быстрый и удобный (пару строчек написать!) способ ненапряжно отфайрволлить/отнатить/зашейпить, например, офис. Или квартиру. Но для серьезной провайдерской работы он не годится принципиально. :-) ipfw - наше все! И с годами становится все лучше и лучше...

Во фре pf находиться на уровне 4.1 openbsd, уже openbsd 4.6 на подходе изменений в pf выше крыши между 4.1 и 4.6.

 

ALTQ изначально не являеться шейпером, это QoS фреймвёрк, шейпинг это лишь побочный продукт.

 

Если так хочеться именно ALTQ, то в NetBSD (pf/altq там тоже есть на уровне openbsd 4.2)ещё сохранился altqd изначальный, у него функционал побольше чем у pf/altq (не полноценный порт), может быть он подойдёт.

 

Про pf/altq, наверно мало кто знает, что когда делали этот порт в нём ещё заложили функцию ALTQ_CDNR, но в силу каких то причин его не доделали. В ядро портировали а вот сам pf, его понимать не научили. Эта опция позволяет делать простейший policing для входящего траффика, если трафик превышает заданный rate limit то он дропаеться, проше говоря будет "шейпинг входящего траффика"(хотя шейпингом там и не пахнет :))). На его основе ещё сделан трёхцветный маркер который может метить пакеты в зависимости от их rate limit'a.

 

Вообще кому интересно, может доделать :)

Edited by windows_NT

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this