Jump to content

Использование PF у провайдеров  

143 members have voted

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

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


Recommended Posts

Posted

В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 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
...

  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Posted

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

Posted

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

Posted

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

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

 

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

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

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

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

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

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

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

 

Posted

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

Posted

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

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

 

 

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

 

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

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

 

 

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.

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

Posted

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

 

1. Нет.

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

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

 

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

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

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

 

1. Нет.

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

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

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

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

 

 

photon -

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

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

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

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

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

В 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
Posted
В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 1500+ абонентам на разные скорости и по разным направлениям.

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

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

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

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

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

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

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

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

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

Posted (edited)
я описывал не так давно как работала у нас дисциплина hfsc

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

Edited by photon
Posted

Добавлю свои пять копеек. :-) В свое время тоже повелся на 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 - наше все! И с годами становится все лучше и лучше...

Posted (edited)
В общем ситуация следующая: Есть сервер, который нарезает полосу порядка 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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.