The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз iptables 1.4.10

30.10.2010 00:14

Вышло очередное обновление iptables, набора userspace-утилит для управления встроенным в ядро Linux фреймворком фильтрации и преобразования пакетов netfilter.

В новом релизе обеспечена полная совместимость с недавно вышедшим ядром 2.6.36, включая поддержку таких возможностей, как:

  • Критерий cpu, позволяющий выделять пакеты по привязке к процессорному ядру, на котором они в данный момент обрабатываются. В частности, этот критерий можно использовать для максимизации использования кэша CPU, обеспечив полную обработку каждого пакета в пределах одного процессорного ядра. Привязав серверный обработчик к конкретному ядру и заданному порту, можно отправлять на этот порт все пакеты, обрабатываемые данным ядром. Так, например, будет выглядеть набор правил при наличии четырех процессорных ядер, по одному серверному процессу на каждое ядро:
    
          iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 0 -j REDIRECT --to-port 8080
          iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 1 -j REDIRECT --to-port 8081
          iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 2 -j REDIRECT --to-port 8082
          iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 3 -j REDIRECT --to-port 8083
    
  • Критерий ipvs, предоставляющий возможность классифицировать пакеты по параметрам IPVS (развивающегося в рамках проекта Linux Virtual Server инструмента для балансировки соединений между несколькими серверами). В частности, к таким параметрам относятся привязанные к текущему соединению виртуальный адрес и/или виртуальный порт (виртуальные адрес-порт представляют кластеризованный средствами IPVS сервис «снаружи», так, что поступающие на них соединения автоматически балансируются между нодами кластера), что позволяет разделять пакеты на основании принадлежности к тому или иному кластерному сервису.
  • Действие IDLETIMER, предоставляющее механизм для отслеживания моментов простоя сетевого интерфейса. Оно обеспечивает отправку уведомления в userspace, если в течение заданного периода времени через выбранный интерфейс не прошло ни одного пакета. Таким образом можно, например, автоматически отключать бездействующие сетевые карты для уменьшения энергопотребления.
  • Действие CHECKSUM, предоставляющее workaround для приложений, некорректно работающих в сочетании с аппаратными реализациями сверки контрольных сумм пакетов. С помощью данного действия можно обеспечить принудительный пересчет контрольных сумм для конкретного класса пакетов, что позволяет избежать необходимости полного отключения checksum offload.

Кроме того, добавлена возможность удаления правил с заданным значением счетчика квоты (критерий quota), а также улучшена документация.

  1. Главная ссылка к новости (http://lists.netfilter.org/pip...)
  2. OpenNews: Релиз iptables 1.4.9
  3. OpenNews: Релиз пакетного фильтра iptables 1.4.8
  4. OpenNews: Релиз пакетного фильтра iptables 1.4.7
  5. OpenNews: Вышло обновление пакетного фильтра iptables 1.4.6
  6. OpenNews: Вышел релиз пакетного фильтра iptables 1.4.5
Автор новости: Sergey Ptashnick
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/28463-iptables
Ключевые слова: iptables, netfilter, firewall
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:09, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    стринг стал меньше тупить?
     
     
  • 2.2, Xaionaro (ok), 10:25, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Хм. А он когда-то тупил? Лично мне было бы интересно увидеть пример правила, которое работает не так, как предполагается :)
     
     
  • 3.3, Онаним (?), 11:12, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    да пожалуйста
    -m conntrack --ctstate INVALID -j DROP
    когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс) - дропит всё подряд.
     
     
  • 4.4, аноним (?), 11:31, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс) - дропит всё подряд.

    RTFM, newbie.

    >Possible states are INVALID meaning that the packet could not be identified for some reason which includes running out of memory

    Hint: http://www.popoff.net.ua/2008/10/netfilter_conntrack_tuning/2/

     
  • 4.5, Xaionaro (ok), 15:12, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > да пожалуйста
    > -m conntrack --ctstate INVALID -j DROP
    > когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс)
    > - дропит всё подряд.

    А вы не забыли увеличить значение опции в sysctl, которая, например, у меня в системах завётся "net.ipv4.netfilter.ip_conntrack_max"? Хотя, кажется, товарищ постом выше уже даже ссылку дал :)

     
     
  • 5.6, Онаним (?), 16:31, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это было одно из самых первых действий:
    net.ipv4.netfilter.ip_conntrack_max = 1048576
    net.netfilter.nf_conntrack_max = 1048576
    net.nf_conntrack_max = 1048576
    net.ipv4.netfilter.ip_conntrack_buckets = 262144
    net.netfilter.nf_conntrack_buckets = 262144
    net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1
    net.netfilter.nf_conntrack_tcp_be_liberal = 1

    cat /sys/module/nf_conntrack/parameters/hashsize
    262144

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

     
     
  • 6.8, Xaionaro (ok), 16:51, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > net.nf_conntrack_max = 1048576
    > net.ipv4.netfilter.ip_conntrack_buckets = 262144
    > net.netfilter.nf_conntrack_buckets = 262144
    > net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1
    > net.netfilter.nf_conntrack_tcp_be_liberal = 1
    > cat /sys/module/nf_conntrack/parameters/hashsize
    > 262144
    > За ссылку, конечно, спасибо - она укрепила мою уверенность, что я ничего
    > не упустил, когда занимался любовью с iptables (хотя таких ссылок я
    > нагуглил и просмотрел столько, что их можно в бочонках солить).

    Как узнавали кол-во соединений?

     
     
  • 7.10, Онаним (?), 18:10, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    netstat -4n | wc
    или
    netstat -4n | grep <чево-нибудь> | wc
     
     
  • 8.12, Онаним (?), 18:32, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    опа, я уже гоню под конец рабочего дня - -4 это опция для BSD шного sockstat ... текст свёрнут, показать
     
  • 8.27, Xaionaro (ok), 12:31, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, вот и ошибка Надо узнать кол-во соединений в conntrack, а не в netstat Сов... текст свёрнут, показать
     
  • 6.9, anonymous (??), 17:43, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    hashsize=1048576
    установить не пробовали? Или памяти мало на данной машинке?
     
     
  • 7.11, Онаним (?), 18:31, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > hashsize=1048576
    > установить не пробовали? Или памяти мало на данной машинке?

    nf_conntrack_max=hashsize - нет, а вот 2M/512k - было, только дело, скорее всего, не в этом, число соединений до 256k всё равно не дотягивает.
    М.б. дело в каких-то ещё других буферах - на каком-то форуме мне попадалась инфа, что conntrack также выполняет сборку фрагментированных IP-пакетов в цепи PREROUTING фильтра raw, даже если там нет ни одного правила (потому что пакет надо оценить до того, как он попадёт "родному" IP'шному сборщику фрагментов). Пруф не скажу, всё было давно...

     
  • 4.14, Sw00p aka Jerom (?), 19:00, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > да пожалуйста
    > -m conntrack --ctstate INVALID -j DROP
    > когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс)
    > - дропит всё подряд.

    дык по дефолту коннекшен трекин маленький 65 тысяч с чемто

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

    учтите при рестарте файервола значение коннекшен трекинга стоновтися дефолтовым (65 тысяч с чемто)

     
  • 2.13, Sw00p aka Jerom (?), 18:57, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    хех дык вы его готовить не могёте

    работает нормульно

    там лучше всего гексы юзать если хотите парсить 7 лейер

     

  • 1.7, Anonym (?), 16:50, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отлично.
    Народ а кто знает, как редиректить широковещательные пакеты на определенный адрес?

    Допустим такое правило:

    iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT --to-destination 192.168.111.53:137

    Вообще должно работать? Есть необходимость пробрасывать некоторые броадкасты на определенный venet-интерфейс.

     
     
  • 2.15, Sw00p aka Jerom (?), 19:02, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Отлично.
    > Народ а кто знает, как редиректить широковещательные пакеты на определенный адрес?
    > Допустим такое правило:
    > iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT
    > --to-destination 192.168.111.53:137
    > Вообще должно работать? Есть необходимость пробрасывать некоторые броадкасты на определенный
    > venet-интерфейс.

    вроде должно - проверьте

     
  • 2.16, non anon (?), 20:04, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT --to-destination 192.168.111.53:137

    Если они без этого правила не проходят, то вряд ли будут проходить и с ним.
    Когда адрес не получает соответствующие ему броадкасты, речь идет о неправильной настройки сети (фильтрация, sysctl, ip ad, ip ro, etc).

     
     
  • 3.24, Sugar (ok), 17:45, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT --to-destination 192.168.111.53:137
    > Если они без этого правила не проходят, то вряд ли будут проходить
    > и с ним.
    > Когда адрес не получает соответствующие ему броадкасты, речь идет о неправильной настройки
    > сети (фильтрация, sysctl, ip ad, ip ro, etc).

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

     
  • 2.18, Michael Shigorin (ok), 21:36, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть необходимость пробрасывать некоторые броадкасты
    > на определенный venet-интерфейс.

    Хм, а сам venet их умеет?  veth-то да...

     
     
  • 3.23, Sugar (ok), 17:39, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уметь-то умеет, но только в если его в мост с физ. интерфейсом положить.

    Насколько я вкурил iptables, DNAT должен менять поле получателя, т.е. 192.168.111.255:137 на 192.168.111.53:137. Но почитав заморские форумы, понял, что он этого не делает.

    Поэтому да, придется бридж громоздить в котором будут лежать veth и eth.

     

  • 1.17, Аноним (-), 21:35, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А скажите как редиректить с одного сервера на другой?
    То есть у меня два сервера. Один в США, а другой в России. И надо, чтобы при коннекте на порт 80-й к серверу в США шел проброс на 80-й порт в России. Это iptables может? А то я с pf пробовал, спрашивал, так ничего и не получилось.
     
     
  • 2.19, Michael Shigorin (ok), 21:38, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Это iptables может?

    У Вас может получиться или асимметричный NAT, или надо будет его подпирать соответствующей маршрутизацией.  IIRC выходит A -> B -> C, C видит пакет с src A и отвечает прямиком на A, но там-то ждут ответ от B.

     
     
  • 3.20, Аноним (-), 21:45, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну мне приходилось решать через portfwd или datapipe (datapipe.c). Решение userspace, а хотелось бы на уровне ядра через iptables.
     
  • 2.21, cub.uanic (?), 02:51, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно может. С незапамятных времён.

    Двойной НАТ спасёт при такой постановке задачи. В одном правиле меняете dst ip (на российский), а потом в другом scr ip (на штатовский). Но надо учитывать, что при таком решении российская машина будет видеть все коннекты как приходящие со штатовской машины, а не с настоящего клиента.

    Если вам на российской машине надо отслеживать ip клиента - есть другой вариант: в штатах поставить nginx или Апач как реверс-прокси, и одновременно с пересылкой запроса генерить заголовок X-Forwarded-For. При этом естественно ожидается, что российская сторона умеет обрабатывать этот самый заголовок. Но это уже user-level, а не iptables.

    На самом деле вы просто определитесь - а что вам надо: решить определённую задачу или решить определённую задачу средствами iptables.

     
     
  • 3.22, Аноним (-), 09:57, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Двойной НАТ, да, двойной НАТ нужен. Точно. Спасибо.

    80-й порт я привел для примера. Конечно, nginx очень подходит, если дело касается http/https.

     

  • 1.25, МестныйАноним (ok), 09:18, 01/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Самое плохое, что в IPv6 ната не будет.

    > When is support NAT table for Ip6tables?

    Only over my dead body. We will never implement ipv6-to-ipv6 network address translation as long as I have any say in netfilter/iptables development. NAT is evil and causes horrible breakage of end-to-end on the internet. IPv6 has enough addresses and therefore no justification for NAT.

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

     
     
  • 2.28, Vitaly_loki (ok), 13:54, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем в IPv6 NAT?
     
     
  • 3.29, Xaionaro (ok), 14:02, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А зачем в IPv6 NAT?

    Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать и в других целях (не только из-за отсутствия адресов). Хоть и чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов :)

     
     
  • 4.30, zazik (ok), 14:19, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> А зачем в IPv6 NAT?
    > Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать
    > и в других целях (не только из-за отсутствия адресов). Хоть и
    > чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов
    > :)

    Например?

     
     
  • 5.31, МестныйАноним (ok), 14:49, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> А зачем в IPv6 NAT?
    >> Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать
    >> и в других целях (не только из-за отсутствия адресов). Хоть и
    >> чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов
    >> :)
    > Например?

    Ну например REDIRECT в IPv6 под линукс отсутсвует, т.к. для работы в IPv4 использовался нат.

    > There is unfortunately no REDIRECT for ip6tables at this moment.  We're currently
    > discussing some ideas how to implement REDIRECT like functionality (for transparent
    > proxes on the local host) without requiring NAT.  This discussion is not finished,
    > and there is no implementation so far.

    И уже лет 5 как ищут способ. У меня уже повяилось желание написать в рассылку что-нибудь типа "Harald Welte, are you still alive?" =)

     
     
  • 6.32, МестныйАноним (ok), 14:57, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    или уже появился =)

    http://netfilter.org/projects/iptables/files/changes-iptables-1.4.10.txt
    > extensions: REDIRECT: add random help

    Надо будет еще раз изучить этот вопрос. Но желание всё равно не пропало =)


     
  • 5.33, Xaionaro (ok), 11:59, 03/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> А зачем в IPv6 NAT?
    >> Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать
    >> и в других целях (не только из-за отсутствия адресов). Хоть и
    >> чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов
    >> :)
    > Например?

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

    Иногда мне требуется натирование из диагностических целей. А если говорить про DNAT, то он мне не так давно требовался, чтобы обойти глюк одной програмки. Да и вообще, неужели не очевидно, что как и SNAT, так и DNAT - мягко говоря необходимы, в любом профессиональном фаерволле?

     
     
  • 6.34, hunter64 (?), 14:12, 05/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Xaionaro - полностью согласен!
    Те кто удалил: NAT - "думали" головой между ног. :(
    NAT - был, есть и будет всегда, это аксиома.
    Маршрутизацию без: NAT - сделать возможно, но будет
    страшный геморой, замешанный на костылях. :(

    P.S. Для танкистов: попробуйте настроить обмен трафиком
    в сети из двух (инет-сервер, рабочая станция) и более
    компов, я очень хочу посмотреть на Ваши закипающие моСки.
    Или вот еще веселее задача, обмен трафиком между сетями:
    инет, диалап, вай-фай, локаль, защищенный периметр.
    А теперь что-ить удвоить по числу объектов ....
    И на закуску: умножить все, и еще балансировка.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру