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)

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

>Найдите эти строчки в моей цитате ;)

Найдите эти строчки в исходниках ядра самостоятельно. Еще одна подсказка: они находятся чуть выше первого процитированного вами куска кода.

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

И да, где обещанное решение задачки?

Тривиальщина же. Каждая группа адресов засовывается в свой recent, подсети можно пихнуть отдельными правилами. Потом через tc ... fw создается корневая очередь, в которой задаются параметры вложенных очередей в соответствии с правилом minor == mark.

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

>он и останется одностраничным, я гарантирую

Фрактал, ты ошибся :-)

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

> Тривиальщина же. Каждая группа адресов засовывается в свой recent, подсети можно пихнуть отдельными правилами. Потом через tc ... fw создается корневая очередь, в которой задаются параметры вложенных очередей в соответствии с правилом minor == mark.

На одну полосу — два правила (вход/исход)

Каждые 10 правил — минус 10kpps. 100 правил — 100 kpps, а это уже не так мало.

Это неприемлемо.

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

>На одну полосу — два правила (вход/исход)

Не стоит забывать, что в случае с xtables каждое из них вызывается из соответствующего хука и поэтому действует только на свой поток.

Каждые 10 правил — минус 10kpps. 100 правил — 100 kpps, а это уже не так мало.

Забавные у вас цифры. С тех же грибов, с которых recent тормозит?

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

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

> на очень паршивом железе.

Отличный ход — все что ниже самого топового, называть «очень паршивое» ;)

redixin ★★★★
()

lol, ipv6 был доступен прогрессивному человечеству еще 5 лет назад в висте, говноеды

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