Jump to content
Калькуляторы

dummynet in linux & dnat забороть совместный функционал netfilter+dummynet

Доброго времени всем.

 

Помогите разобраться в следующей теме. Стоит Linux-router, озадаченный транзитом абонентского трафика (IPoE) в интернет. Для шейпинга установлен порт ipfw+dummynet под Linux. Некоторую нехитрую фильтрацию и абонентов с серыми айпи реализует iptables+netfilter.

Блокировние должников реализовано добавлением их в заданную таблицу ipfw, которая дропается. И вот настал момент расширить работу с должниками. А имеено реализовать не обычный drop, а любой запрос на 80 порт кинуть на другой хост, на котором абоненту будет сообщено, что он должник и пора бы заплатить. Однако функционал NAT в Linux из ipfw у меня не заработал, а в iptables нет удобных таблиц, куда затолкать должников для сей операции. А забивать в iptables тучу правил iptables DNAT не очень оптимально и красиво.

 

Какие есть варианты обойти и решить данную задачу? Возможно я чего либо не учел или не знаю.

 

Заранее спасибо за любый светлые мысли. :)

 

 

Share this post


Link to post
Share on other sites

создаем цепочку для редиректа, и всех должников в нее заворачиваем. а в цепочке одно правило.

iptables -t mangle -N redirect

iptables -t mangle -A PREROUTING -s $ip -j redirect

iptables -t mangle -A redirect -p tcp --dport 80 -j DNAT --to ip:port

 

Share this post


Link to post
Share on other sites

Человек скорее всего имеет ввиду, что список правил с IP должников будет длинным. Для этого смотрите ipset - и быстро и удобно.

Share this post


Link to post
Share on other sites
Человек скорее всего имеет ввиду, что список правил с IP должников будет длинным. Для этого смотрите ipset - и быстро и удобно.

Да, вот, видимо, ipset - то что требуется. Спасибо - давно о нем слышал, но руки не доходили прокурить.

Тогда уж в топик еще есть вопрос - а нет ли еще адекватного варианта Линуксового, чтобы не городить dummynet, при этом не теряя в производительности.

Исходное условие - абоненты имеют свой айпи и тариф, однако никакой зависимости между айпи и тарифом нет. Нужно ограничить скорость туда/обратно согласно тарифа, при этом обычный tc u32 классифаер, полагаю, очень быстро уложит систему на лопатки, а хеши вероятно не в тему. Или я не прав?

Share this post


Link to post
Share on other sites

tc u32 + хэши как раз то что нужно. Посмотрите на предмет шейпинга еще http://forum.nag.ru/forum/index.php?showtopic=48301

Как раз таки порт ipfw+dummynet под линуксом лишнее )

Share this post


Link to post
Share on other sites

Интересно, а в линуксовой версии dummynet тоже есть ошибка с отсутствием шейпинга для полос пропускания выше 12Мбит/с при HZ=1000 ?

Edited by photon

Share this post


Link to post
Share on other sites

Всякие извращения видел, но вот ipfw+dummynet под линухом - впервые o_O.

Share this post


Link to post
Share on other sites
Интересно, а в линуксовой версии dummynet тоже есть ошибка с отсутствием шейпинга для полос пропускания выше 12Мбит/с при HZ=1000 ?

Было дело, не помню точно от чего зависящее, но Луиджи выслал обновления и проблема решилась. Если не ошибаюсь грабля всплывала только при включенном io_fast.

 

Всякие извращения видел, но вот ipfw+dummynet под линухом - впервые o_O.

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

Share this post


Link to post
Share on other sites

heap

Собственно вопрос в том, почему Вы используется порт ipfw, что мешает просто использовать freebsd, т.е. зачем нужен linux?

Share this post


Link to post
Share on other sites

Действительно, если больше нравится ipfw+dummynet, то лучше сделать шейпер-мост на FreeBSD с правилами вида pipe tablearg. Что касается captive portal на iptables, то тут надо скорее делать не DNAT, а -j REDIRECT на локальный веб-сервер, как при прозрачном проксировании.

Edited by photon

Share this post


Link to post
Share on other sites
Действительно, если больше нравится ipfw+dummynet, то лучше сделать шейпер-мост на FreeBSD с правилами вида pipe tablearg. Что касается captive portal на iptables, то тут надо скорее делать не DNAT, а -j REDIRECT на локальный веб-сервер, как при прозрачном проксировании.

 

Собственно задача чуть более широка. С одной стороны давно не крутил в руках FreeBSD (хотя на самом деле это и не причина). С другой стороны вопрос распараллеливания обработки трафика. В Linux имел дело как с bonding и smp_affinity, так и с драйверами на кучу irq. Во FreeBSD такого крутить не приходилось, да и производительность порта вроде не уступает Фришной реализации. И как еще один не совсем весомый фактор холиварный - с Линуксом во многих ипостасиях варится приходится, с Фрей редко. Потому на Линуксе многие грабли, так сказать, уже проходили, а на Фре потенциально заново топтаться по граблям и искать решения. Вобщем, математически точного ответа и сам затрудняюсь дать. :)

 

А про редирект - ну если один сервер, то да - вопросов нет. А вот если и серверов несколько, и страничку хотелось бы не просто хтмл типа "денек дай", а как часть основного сайта или полноценной страницы оплаты.

Share this post


Link to post
Share on other sites

А про редирект - ну если один сервер, то да - вопросов нет. А вот если и серверов несколько, и страничку хотелось бы не просто хтмл типа "денек дай", а как часть основного сайта или полноценной страницы оплаты.

Для этого сделай либо отдельный домен, либо отдельный порт и апачевским проксированием выставь нужный корень сайта или конкретную страницу :)

Share this post


Link to post
Share on other sites
А про редирект - ну если один сервер, то да - вопросов нет. А вот если и серверов несколько, и страничку хотелось бы не просто хтмл типа "денек дай", а как часть основного сайта или полноценной страницы оплаты.
Для этого сделай либо отдельный домен, либо отдельный порт и апачевским проксированием выставь нужный корень сайта или конкретную страницу :)

Ну я в том смысле, что вероятно таки DNAT веселее. Или я не могу понять недостатка DNAT перед REDIRECT.

Share this post


Link to post
Share on other sites
tc u32 + хэши как раз то что нужно. Посмотрите на предмет шейпинга еще http://forum.nag.ru/forum/index.php?showtopic=48301

Как раз таки порт ipfw+dummynet под линуксом лишнее )

Посмотрел. В итоге то ли в силу криворукости, то ли в силу иных причин, вот результаты:

1. Для начала захотелось попробовать режим flow. Прочитав вместо документации, которой нет, коменты в конфиге, что оно работает только с маской 16 для одной подсети - записал для теста подсеть: 10.10.0.0/16.

заинитил sc, создался ipset, фильтры и дисциплины. сделал sc add 10.10.1.2 10Mibit и получил все 100Мбит. Есть подозрение, что неверно понимаю логику этого самого flow.

2. Пошел в сторону u32. Первый возникший вопрос, на который пока не искал ответ чтением кода скрипта - а нельзя ли не дропать все лишнее, а только зашейпить нужное?

Далее - добавил таки свой и внешний айпи сервера, померял спидтестом скорость. Вход обжался. Исход нет (если верно понял - в силу NAT, а на внешнем интерфейсе несколько иной айпи). Это из базового комплекта, полагаю забороть как-то можно.

А вот на закуску осталась задача - трафик то хоть и не сильно, а порезан тематически следующим образом: на определенные направления (местный IX и т.д.) скорость не резать. На другие резать согласно тарифного плана для каждого айпи. Были ли попытки тулзой решить поставленные задачи?

Share this post


Link to post
Share on other sites
tc u32 + хэши как раз то что нужно. Посмотрите на предмет шейпинга еще http://forum.nag.ru/forum/index.php?showtopic=48301

Как раз таки порт ipfw+dummynet под линуксом лишнее )

Посмотрел. В итоге то ли в силу криворукости, то ли в силу иных причин, вот результаты:

1. Для начала захотелось попробовать режим flow. Прочитав вместо документации, которой нет, коменты в конфиге, что оно работает только с маской 16 для одной подсети - записал для теста подсеть: 10.10.0.0/16.

заинитил sc, создался ipset, фильтры и дисциплины. сделал sc add 10.10.1.2 10Mibit и получил все 100Мбит. Есть подозрение, что неверно понимаю логику этого самого flow.

Документация есть: man sc и man sc.conf. Собирается из pod и устанавливается в нужные каталоги по make install. Что касается отсутствия шейпинга, подозреваю, что есть проблемы с NAT или перепутаны внутренний/внешний интерфейсы.

Share this post


Link to post
Share on other sites
tc u32 + хэши как раз то что нужно. Посмотрите на предмет шейпинга еще http://forum.nag.ru/forum/index.php?showtopic=48301

Как раз таки порт ipfw+dummynet под линуксом лишнее )

Посмотрел. В итоге то ли в силу криворукости, то ли в силу иных причин, вот результаты:

1. Для начала захотелось попробовать режим flow. Прочитав вместо документации, которой нет, коменты в конфиге, что оно работает только с маской 16 для одной подсети - записал для теста подсеть: 10.10.0.0/16.

заинитил sc, создался ipset, фильтры и дисциплины. сделал sc add 10.10.1.2 10Mibit и получил все 100Мбит. Есть подозрение, что неверно понимаю логику этого самого flow.

Документация есть: man sc и man sc.conf. Собирается из pod и устанавливается в нужные каталоги по make install. Что касается отсутствия шейпинга, подозреваю, что есть проблемы с NAT или перепутаны внутренний/внешний интерфейсы.

В принципе уже разобрался, однако решил наваять свое решение под ситуацию. Если будет интересно, то вот почему:

1. Таки не ушли мы еще от абонентиков с серыми айпи. А шейпить надо бы и их.

2. Для u32 скриптом генерирую правила с матчингом по всем октетам, точнее сначала 1й, потом 2й, потом 3й и по четвертому уже заворачиваю в класс. Получается веселее, тем более с учетом, что я не хочу дропать все лишнее, мне нужно зашейпить нужное. Очень негодовал, когда запустил sc с u32 и все заблокировалось. Блокирую ipset+iptables.

3. Шейпить надо так, чтобы часть трафика на определенные адреса не шейпить или шейпить на другой скорости.

Итого вывод из всего вышесказанного:

1. Было бы неплохо, чтобы tc filter мог пользоваться ipset или аналогом. Возможно кто-то возьмется припилить такой финт ушами.

2. Учитывая специфику пункта 1 пришлось использовать ifb, а учитывая специфику пункта 3 - теперь готовлю переход на IMQ, ибо в случае с NAT маркировка пакетов в iptables проходит позже, чем я траф заворачиваю на ifb. Обидно. В связи с чем дважды интересен пункт 1 выводов. :)

3. В сухом остатке получается - или ipfw+dummynet собирать для Linux. Или накручивать IMQ, что вообще требует полной пересборки ведра. Вот такая диллема.

 

Не исключаю, что где-то в логике ошибаюсь, прошу поправить ход моих мыслей, если так.

Share this post


Link to post
Share on other sites

heap вы модуль ipfw_mod с какими параметрами подгружаете на Linux ?

 

На моей тестовой машине при обычнои modprobe ipfw_mod

получаю кучу

 

kernel: Bump sched buckets to 64 (was 0)
kernel: dummynet_io dropped by enqueue

 

соответственно правила простейшие

ipfw add pipe 4 src-ip 172.16.0.0/16 in proto udp                               
ipfw pipe 4 config bw 500Kbit/s queue 20 mask src-ip 0x00ffffff

 

не работает :(

Edited by _INF_

Share this post


Link to post
Share on other sites
heap вы модуль ipfw_mod с какими параметрами подгружаете на Linux ?

 

На моей тестовой машине при обычнои modprobe ipfw_mod

получаю кучу

 

kernel: Bump sched buckets to 64 (was 0)
kernel: dummynet_io dropped by enqueue

 

соответственно правила простейшие

ipfw add pipe 4 src-ip 172.16.0.0/16 in proto udp                               
ipfw pipe 4 config bw 500Kbit/s queue 20 mask src-ip 0x00ffffff

 

не работает :(

 

Там проблема в вербосити, если не ошибаюсь. Девелоперы делились сорцами новее, чем есть на оффсайте. Они вроде работают стабильно.

Share this post


Link to post
Share on other sites
Там проблема в вербосити, если не ошибаюсь. Девелоперы делились сорцами новее, чем есть на оффсайте. Они вроде работают стабильно.

Вы свежими сорцами пользуетесь ?

Не поделитесь линком на них ?

 

Модуль с какими параметрами подгружаете ?

Share this post


Link to post
Share on other sites
Там проблема в вербосити, если не ошибаюсь. Девелоперы делились сорцами новее, чем есть на оффсайте. Они вроде работают стабильно.

Вы свежими сорцами пользуетесь ?

Не поделитесь линком на них ?

 

Модуль с какими параметрами подгружаете ?

Сорцы могу кинуть на мыло - пишите в личку адрес. Параметры:

echo 8192 > /sys/module/ipfw_mod/parameters/hash_size
echo 8192 > /sys/module/ipfw_mod/parameters/dyn_buckets
echo 10 > /sys/module/ipfw_mod/parameters/autoinc_step
echo 1 > /sys/module/ipfw_mod/parameters/io_fast

Share this post


Link to post
Share on other sites

Спасибо, модуль действительно работает как надо и без глюков версии с офф. сайта.

Share this post


Link to post
Share on other sites

Спасибо, действительно наилучшее решение для шейпинга под линукс. С tc не сваришь каши при множестве тарифов и куче подсетей, а с фрей не сложились отношения с самого начала - виснет зараза, теряет сетевой линк, ребутится, исчезают файлы в файловой системе сами по себе и еще куча всего - в то время как рядом на том же железе линуксовые серваки работают с годовым аптаймом.

Edited by vladd

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

Если не трудно, то скиньте и мне исходники ipfw3 на мыло ilya.evseev@gmail точка com :)

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