LINUX.ORG.RU

Релиз ipset 5.0

 , , , , ,


0

1

Ipset — компонент универсального фреймворка фильтрации и преобразования пакетов netfilter, предназначенный для хранения больших списков IP-адресов и подсетей, MAC-адресов, TCP/UDP-портов с возможностью быстрого поиска по ним.

Основные новшества:

  • Полная поддержка IPv6
  • Устранено ограничение для списков типа ipporthash, ipportiphash и ipportnethash, предписывавшее, что адреса в пределах одного списка должны принадлежать одному блоку /16, также устранено ограничение для списков типа ipporthash и ipportnethash, запрещавшее сохранять в них адреса хоста, на котором работает ipset
  • Для всех типов списков, сохраняющих номера портов, теперь поддерживается сохранение протокола (TCP/UDP/ICMP, в последнем случае вместо номера порта сохраняется пара значений тип/код ICMP), а также реализована поддержка таймаутов
  • Добавление/удаление нескольких записей в рамках одной транзакции
  • Для связи ядро-userspace теперь используется протокол Netlink
  • Оптимизировано потребление памяти алгоритмом хэширования hash-типов
  • Улучшен синтаксис
  • Добавлен слой совместимости синтаксиса с веткой 4.х

Прежние версии ipset (ветка 4.х) не включались в основную ветку ядра в силу множества замечаний разработчиков Linux в адрес ipset, однако могли быть собраны в виде отдельных модулей. Версия 5, из-за использования Netlink, требует более жёсткой связи с ядром, поэтому для её работы необходима модификация заголовков ядра с последующей пересборкой. Однако устранение вышеупомянутых замечаний разработчиков ядра даёт надежду на скорое включение ipset в основную ветку разработки.

>>> Подробности



Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 2)

По традиции: - решето! - не нужно - чем оно лучше <...>? - я видел этот тред на 1 странице!

anonymous
()
Ответ на: фейл от redixin

а зочем? для больших, огромных сетей есть ipset. Для небольших - хватает цепочек iptables. Так что вброс мимо кассы...

anonymous
()
Ответ на: комментарий от anonymous

ipset удобен не только количественными показателями. Таблицы ipset обновлять значительно удобнее из скриптов, чем правила в ipt.

mashina ★★★★★
()
Ответ на: комментарий от anonymous

> для больших, огромных сетей есть ipset

Так какбэ соль в отсутствии ipset в ванильном ядре

redixin ★★★★
()
Ответ на: комментарий от anonymous

> для больших, огромных сетей есть ipset

Не троллинга ради, но сколько дистров его поддерживают? Так чтобы что-то доставить из репов, но без конпелянья. Один дебиан?

anonymous
()
Ответ на: комментарий от anonymous

>Не троллинга ради, но сколько дистров его поддерживают? Так чтобы что-то доставить из репов, но без конпелянья. Один дебиан?

В Мандриве есть

annulen ★★★★★
()
Ответ на: комментарий от anonymous

>Так чтобы что-то доставить из репов, но без конпелянья

в новости прямо сказано, что теперь без компилянья не получится

Savonarola
() автор топика
Ответ на: комментарий от anonymous

Gentoo. Но он конечно не дистрибутив, а метадистрибутив.

alx_me ★★☆
()

Хм. Позитивная вещь. Я так понимаю, нужна только у провайдеров?

anonymous
()
Ответ на: фейл от redixin

>2011 год на носу, а в лялихе досихпор нету таблиц в фаерволе

Давно уже есть, iptables -m recent.

Fail, dear trolololo!

anonymous
()
Ответ на: комментарий от anonymous

>Не троллинга ради, но сколько дистров его поддерживают? Так чтобы что-то доставить из репов, но без конпелянья. Один дебиан?

И в дебиане с компиляньем, увы! Мышевозы плачут и грызут кактус.

anonymous
()
Ответ на: комментарий от annulen

>В Мандриве есть

В мандриве, afaik, есть только userspace-часть, без поддержки со стороны ядра.

anonymous
()
Ответ на: комментарий от redixin

>Это и близко не то что нужно.

Я не знаю, что нужно толстому троллю (еда, наверное), но recent гораздо круче тех же таблиц pf.

anonymous
()
Ответ на: комментарий от redixin

> Я не знаю, что умеет recent, и что умеет ipset

Я вижу, что вы этого не знаете. А все туда же, троллить лезете.

anonymous
()
Ответ на: комментарий от anonymous

>> Я не знаю, что умеет recent, и что умеет ipset

Я вижу, что вы этого не знаете.

Да ну? Допустим у меня есть список из 100500 ip адресов. Мне нужно их всех заблочить на input. Как мне тут поможет recent?

redixin ★★★★
()
Ответ на: комментарий от redixin

> Допустим у меня есть список из 100500 ip адресов.

ну так в любом случае будет линейный матчинг. или у ipset свой взгляд на это дело?

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

> или у ipset свой взгляд на это дело?

Именно.

redixin ★★★★
()
Ответ на: комментарий от redixin

Да ну? Допустим у меня есть список из 100500 ip адресов. Мне нужно их всех заблочить на input. Как мне тут поможет recent?

Очень сильно поможет.

modprobe xt_recent ip_list_tot=100500
iptables -I INPUT -m recent --rcheck -j DROP
cat 100500ip.txt | while read ip; do echo "+$ip" > /proc/net/xt_recent/DEFAULT; done

Готово!

А ipset пришлось бы побольше париться - больше 65536 записей в одном сете он не держит, поэтому пришлось бы setlist городить.

anonymous
()
Ответ на: комментарий от anonymous

> А ipset пришлось бы побольше париться - больше 65536 записей в одном сете он не держит, поэтому пришлось бы setlist городить.

Городить-не городить, но ты представляешь что будет с машиной которая делает линейный поиск по 100500 значений? С ней будет softirq в топе вверху, и дикие тормоза. Это тоже самое что делать отдельную цепочку и пихать туда все те же 100500 правил.

redixin ★★★★
()
Ответ на: комментарий от redixin

>Городить-не городить, но ты представляешь что будет с машиной которая делает линейный поиск по 100500 значений? С ней будет softirq в топе вверху, и дикие тормоза.

Шо хотели, то и получили. Если не нравятся тормоза - ставьте циско, они не тормозят.

anonymous
()
Ответ на: комментарий от anonymous

> Шо хотели, то и получили.

Да я хотел как минимум ip-set был в ваниле, чтоб не патчить и не пересобирать. Это конечно не таблицы в ipfw, но лучше чем ничего.

Если не нравятся тормоза - ставьте циско, они не тормозят.

Наш выбор — juniper)

redixin ★★★★
()
Ответ на: комментарий от redixin

>Да я хотел как минимум ip-set был в ваниле, чтоб не патчить и не пересобирать.

Наш выбор — juniper)

Противоречите себе. Зачем тем, у кого хватает денег на джуники, нищебродские костыли типа ipset/recent/ipfw?

Это конечно не таблицы в ipfw, но лучше чем ничего.

Вы так говорите, как будто таблицы ipfw чем-то лучшие ipset.

anonymous
()
Ответ на: комментарий от anonymous

> Противоречите себе. Зачем тем, у кого хватает денег на джуники, нищебродские костыли типа ipset/recent/ipfw?

Да ну? Джуники, это как известно, маршрутизаторы. А зачем, позвольте спросить, маршрутизатору что-то блокировать на INPUT?

Напомню:

Допустим у меня есть список из 100500 ip адресов. Мне нужно их всех заблочить на input.

Вы так говорите, как будто таблицы ipfw чем-то лучшие ipset.

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

redixin ★★★★
()
Ответ на: комментарий от redixin

>Да ну? Джуники, это как известно, маршрутизаторы. А зачем, позвольте спросить, маршрутизатору что-то блокировать на INPUT?

Да ну? Неужели у них нет никаких других решений, кроме тупых маршрутизаторов?

Во-первых нет дурацкого ограничения на количество записей

afaik, работают они по тому же принципу, что и recent, поэтому ограничение накладывается производительностью железа.

Кстати, принципиальное ограничение ipset - 4294967296 записей (65536 списков в setlist по 65536 записей) лежит гораздо выше технических возможностей современного роутерного железа.

во-вторых есть такая вкусняшка как tablearg

Это костылек там появился из-за неэффективной структуры правил: linked list в ipfw/pf против concatenated blob в netfilter. В результате tablearg работает примерно с той же скоростью, что и обычный набор правил ip_tables (т.е. несколько быстрее обычного набора правил ipfw/pf), но гибкости там гораздо меньше.

anonymous
()
Ответ на: комментарий от anonymous

> Да ну? Неужели у них нет никаких других решений, кроме тупых маршрутизаторов?

Не такие они уже и тупые ;)

afaik, работают они по тому же принципу, что и recent, поэтому ограничение накладывается производительностью железа.

Таблицы в ipfw работают совсем по другому принципу, и нет там никаких ограничений.

Это костылек там появился из-за неэффективной структуры правил: linked list в ipfw/pf против concatenated blob в netfilter.

ШТО? о_О Какое отношение tablearg имеет к структуре правил? Какая разница что там, linked list или concatenated blob?

В результате tablearg работает примерно с той же скоростью, что и обычный набор правил ip_tables (т.е. несколько быстрее обычного набора правил ipfw/pf), но гибкости там гораздо меньше.

facepalm.tar.gz

Сэр вообще имеет представление что такое tablearg?

redixin ★★★★
()
Ответ на: комментарий от redixin

>Таблицы в ipfw работают совсем по другому принципу, и нет там никаких ограничений.

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

ШТО? о_О Какое отношение tablearg имеет к структуре правил? Какая разница что там, linked list или concatenated blob?

Альтернативой tablearg является добавление кучи правил, например, в цикле for. Так вот, в случае с ipfw/pf это приведет к засорению списка и потере производительности (по сравнению с tablearg). У netfilter, во-первых, есть цепочки, во-вторых, производительность там на уровне (именно из-за того, что он не использует ll).

Сэр вообще имеет представление что такое tablearg?

Да, как раз хотел вас об этом спросить.

anonymous
()
Ответ на: комментарий от anonymous

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

Почему линейного? Сэр заблуждается. Таблицы в ipfw не юзают линейный поиск, поэтому даже на десктопном проце, в тех условиях где линупсовый recent встанет раком, фряшные таблички спокойно шуршат кушая 2% десктопного CPU. Бгг (кстати, ipset тоже справляется наотличненько)

Альтернативой tablearg является добавление кучи правил...

Советую почитать про tablearg, потому что несете какуюто хуиту.

redixin ★★★★
()
Ответ на: комментарий от redixin

>Таблицы в ipfw не юзают линейный поиск, поэтому даже на десктопном проце, в тех условиях где линупсовый recent встанет раком, фряшные таблички спокойно шуршат кушая 2% десктопного CPU.

Это у вас грибы какие-то неправильные. Когда у нас один роутер на фряшке+ipfw+tables заменили на linux+ipset, загрузка проца упала с 50-90% до 2-3%, при этом задержки пакетов ушли с 10-100 мс до ~1 мс. Правил было сколько-то там тысяч, уже не помню.

Советую потестить самостоятельно, а потом вернуться и рассказать о впечатлениях ;-)

Советую почитать про tablearg, потому что несете какуюто хуиту.

По-видимому, вы нифига не понимаете в tablearg, поэтому и не можете осознать одну простую мысль (алгоритмическая взаимозаменяемость tablearg и монотонного набора правил).

anonymous
()
Ответ на: комментарий от anonymous

> Это у вас грибы какие-то неправильные. Когда у нас один роутер на фряшке+ipfw+tables заменили на linux+ipset, загрузка проца упала с 50-90% до 2-3%, при этом задержки пакетов ушли с 10-100 мс до ~1 мс.

Опять несете чушь.

Вот например товарищь провел эксперимент:

http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-August/001347.html

2004й год блеать, а в лялихе досихпор приходится ставить ipset отдельно.

Правил было сколько-то там тысяч, уже не помню.

Несколько тысяч правил это конечно сильно.

У меня например на одной шейпилке стоит 14 правил. (стоит ли говорить о тысячах записей в таблицах). Раньше там был линух с зоопарком из iptables/tc и никто не смог выжать даже половины от того, что мне удалось выжать из freebsd+ipfw+tablearg.

Может нужно было позвать толстоватого трольца с ником anonymous, и он бы все настроил? Бгг.

redixin ★★★★
()
Ответ на: комментарий от redixin

>Вот например товарищь провел эксперимент:

Полгода назад смотрели. Нету там radix lookup, при всем желании его там не увидеть. Обычный O(n).

2004й год блеать, а в лялихе досихпор приходится ставить ipset отдельно.

А еще там софт в пакетах, да. То ли дело жунипер - сразу весь софт из коробки установлен.

Может нужно было позвать толстоватого трольца с ником anonymous, и он бы все настроил? Бгг.

Пожалуй, стоит. С вероятностью 99.99% предполагаю, что все решается одним правилом tc с магическим словом fw и одним правилом iptables с магическим словом IPMARK. Но откуда это знать толстому троллю с ником redixin? :-)

anonymous
()
Ответ на: комментарий от anonymous

> Полгода назад смотрели. Нету там radix lookup, при всем желании его там не увидеть. Обычный O(n).

БУГАГАГАГАГАГАГА

Пожалуй, стоит. С вероятностью 99.99% предполагаю, что все решается одним правилом tc с магическим словом fw и одним правилом iptables с магическим словом IPMARK. Но откуда это знать толстому троллю с ником redixin? :-)

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

redixin ★★★★
()
Ответ на: комментарий от redixin

>БУГАГАГАГАГАГАГА

Не убивайтеся так, все будет хорошо. Лет через десять, глядишь, и во фряхе до O(log(n)) оптимизируют :-)

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

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

anonymous
()
Ответ на: комментарий от anonymous

Не убивайтеся так, все будет хорошо. Лет через десять, глядишь, и во фряхе до O(log(n)) оптимизируют :-)

Та какбэ давно оптимизировали. А вот в линухе таблицы добавят действительно лет через 10. Если вообще добавят.

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

Таблица соответствия же. (Ага, тот самый tablearg)

Кстати вот, залез на последний:

# ipfw show | wc
       9     105     678
# ipfw table 20 list | head
10.12.32.31/32 50001
10.12.32.40/32 50008
10.12.32.85/32 50004
10.12.32.94/32 50011
10.12.32.102/32 50001
10.12.32.136/32 50003
10.12.32.195/32 50011
10.12.32.202/32 50011
10.12.32.205/32 3265
10.12.32.218/32 50001
# ipfw pipe 50001 show | grep "/s"
50001:   1.024 Mbit/s    0 ms burst 0 

9 правил ёпт.

redixin ★★★★
()
Ответ на: комментарий от redixin

>Та какбэ давно оптимизировали.

Все в мечтах, а до реальности лет через десять дойдет.

А вот в линухе таблицы добавят действительно лет через 10. Если вообще добавят.

Так recent там уже давно и прочно :-)

Таблица соответствия же. (Ага, тот самый tablearg)

Т.е. корейский random. Тогда тут тяжелая артиллерия (в лице IPMARK) уже не нужна. Достаточно recent/ipset/обычных цепочек + маркировки + самых обычные очереди.

anonymous
()
Ответ на: комментарий от anonymous

Все в мечтах, а до реальности лет через десять дойдет.

http://files.sharenator.com/go_be_fat0_Some_moar_awesome_stuff_D-s500x386-388...

Так recent там уже давно и прочно :-)

recent тормозит.

Т.е. корейский random. Тогда тут тяжелая артиллерия (в лице IPMARK) уже не нужна. Достаточно recent/ipset/обычных цепочек + маркировки + самых обычные очереди.

Это всё? Тоесть сдаетесь?

redixin ★★★★
()
Ответ на: комментарий от redixin

>recent тормозит.

Если у вас recent тормозит, то таблицы ipfw, наверное, вообще не едут :-)

Это всё? Тоесть сдаетесь?

Я с кем-то воевал? O_o

anonymous
()
Ответ на: комментарий от anonymous

> Если у вас recent тормозит

Он у всех тормозит ;) Если у Вас «летает», то Вы просто не в курсе как бывает)

Я с кем-то воевал? O_o

Нет, но грозились запилить 2 магических правила.

Троль попался невкусный. Толстый и глупый. ЛОР уже не торт.

redixin ★★★★
()
Ответ на: комментарий от redixin

>Он у всех тормозит ;)

Без грибов тормоза не работают :-)

Если чуть серьезней, предъявите мне нотариально заверенные заявления, что recent тормозит. Ото ВСЕХ.

Нет, но грозились запилить 2 магических правила.

2 магических правила работают в особо тяжелом случае - когда *каждому* айпишнику из некоего диапазона нужна своя очередь (в возможностью независимой настройки параметров шейпинга). Есличо, посмотреть их можно в man iptables, в разделе про IPMARK. Что характерно, там вообще не используются таблицы - только арифметика.

В вашем случае задача менее интересна - достаточно выставлять маркировку на основании некоторой таблицы адресов источников. Админ, не злоупотребляющий этими веществами, решит задачку средствами recent или ipset за пять минут. И тормозить оно не будет (опять-таки, если не злоупотреблять средствами для изменения сознания).

anonymous
()
Ответ на: комментарий от redixin

>Троль попался невкусный. Толстый и глупый.

Дожили. Еда жалуется на вкусовые качества того, кто ее жует.

ЛОР уже не торт.

Таки да.

anonymous
()
Ответ на: комментарий от anonymous

Если чуть серьезней, предъявите мне нотариально заверенные заявления, что recent тормозит. Ото ВСЕХ.

Пожалуйста:

«net/netfilter/xt_recent.c» 685 стр. --26%--

static struct recent_table *recent_table_lookup(const char *name)
{
    struct recent_table *t;

    list_for_each_entry(t, &tables, list)
        if (!strcmp(t->name, name))
            return t;
    return NULL;
}

«include/linux/list.h» 695 стр. --57%--

#define list_for_each_entry(pos, head, member)              \
    for (pos = list_entry((head)->next, typeof(*pos), member);  \
         prefetch(pos->member.next), &pos->member != (head);    \
         pos = list_entry(pos->member.next, typeof(*pos), member))

Попахивает linked list'ом ;)

решит задачку средствами recent или ipset за пять минут

Тафай-тафай ;)

redixin ★★★★
()
Ответ на: комментарий от redixin

>Попахивает linked list'ом ;)

И что, поиск таки по всему списку идет?

Ладно, так и быть, подскажу. Обратите внимание на следующие строчки:

h = recent_entry_hash4(addrp); // или hash6

и

&table->iphash[h]

И не позорьтесь так больше. recent у него тормозит, блин...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.