Перейти к содержимому
Калькуляторы
Использование PF у провайдеров  

143 пользователя проголосовало

  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
...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

ng_car - шейпер.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну я не говорю, что pf совсем не нужен. На бордере для NAT

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

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.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

1. Нет.

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Существует патч для вызова dummynet из pf:

http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/...hes/RELENG_7_1/

 

Подробности можно узнать через Гугл по запросу "pf dummynet patch".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

1. Нет.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

photon -

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем 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.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.