Вышло (http://lists.netfilter.org/pipermail/netfilter-announce/2010...) очередное обновление iptables, набора userspace-утилит для управления встроенным в ядро Linux фреймворком фильтрации и преобразования пакетов netfilter (http://www.netfilter.org/).
В новом релизе обеспечена полная совместимость с недавно вышедшим (http://www.opennet.me/opennews/art.shtml?num=28363) ядром 2.6.36, включая поддержку таких возможностей, как:
- Критерий cpu, позволяющий выделять пакеты по привязке к процессорному ядру, на котором они в данный момент обрабатываются. В частности, этот критерий можно использовать для максимизации использования кэша CPU, обеспечив полную обработку каждого пакета в пределах одного процессорного ядра. Привязав серверный обработчик к конкретному ядру и заданному порту, можно отправлять на этот порт все пакеты, обрабатываемые данным ядром.
Так, например, будет выглядеть набор правил при наличии четырех процессорных ядер, по одному серверному процессу на каждое...URL: http://lists.netfilter.org/pipermail/netfilter-announce/2010...
Новость: http://www.opennet.me/opennews/art.shtml?num=28463
стринг стал меньше тупить?
Хм. А он когда-то тупил? Лично мне было бы интересно увидеть пример правила, которое работает не так, как предполагается :)
да пожалуйста
-m conntrack --ctstate INVALID -j DROP
когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс) - дропит всё подряд.
>когда число соединений достигает десятков тысяч (особенно когда оно выше 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/
> да пожалуйста
> -m conntrack --ctstate INVALID -j DROP
> когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс)
> - дропит всё подряд.А вы не забыли увеличить значение опции в sysctl, которая, например, у меня в системах завётся "net.ipv4.netfilter.ip_conntrack_max"? Хотя, кажется, товарищ постом выше уже даже ссылку дал :)
Это было одно из самых первых действий:
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 = 1cat /sys/module/nf_conntrack/parameters/hashsize
262144За ссылку, конечно, спасибо - она укрепила мою уверенность, что я ничего не упустил, когда занимался любовью с iptables (хотя таких ссылок я нагуглил и просмотрел столько, что их можно в бочонках солить).
>[оверквотинг удален]
> 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 (хотя таких ссылок я
> нагуглил и просмотрел столько, что их можно в бочонках солить).Как узнавали кол-во соединений?
netstat -4n | wc
или
netstat -4n | grep <чево-нибудь> | wc
> netstat -4n | wc
> или
> netstat -4n | grep <чево-нибудь> | wcопа, я уже гоню под конец рабочего дня - "-4" это опция для BSD'шного sockstat :)
> netstat -4n | wc
> или
> netstat -4n | grep <чево-нибудь> | wcНу, вот и ошибка. Надо узнать кол-во соединений в conntrack, а не в netstat. Советую поставить управляющую утилиту с одноимённым названием для conntrack и посмотреть в "conntrack -L".
Например тупо натированное соединение проходящие FORWARD-ом через ваш роутер никогда не отобразится в netstat.
hashsize=1048576
установить не пробовали? Или памяти мало на данной машинке?
> hashsize=1048576
> установить не пробовали? Или памяти мало на данной машинке?nf_conntrack_max=hashsize - нет, а вот 2M/512k - было, только дело, скорее всего, не в этом, число соединений до 256k всё равно не дотягивает.
М.б. дело в каких-то ещё других буферах - на каком-то форуме мне попадалась инфа, что conntrack также выполняет сборку фрагментированных IP-пакетов в цепи PREROUTING фильтра raw, даже если там нет ни одного правила (потому что пакет надо оценить до того, как он попадёт "родному" IP'шному сборщику фрагментов). Пруф не скажу, всё было давно...
> да пожалуйста
> -m conntrack --ctstate INVALID -j DROP
> когда число соединений достигает десятков тысяч (особенно когда оно выше 40 тыс)
> - дропит всё подряд.дык по дефолту коннекшен трекин маленький 65 тысяч с чемто
в реалтайме через сисктл надо увеличивать и желательно при больших нагрузках вырубать син кукисы
учтите при рестарте файервола значение коннекшен трекинга стоновтися дефолтовым (65 тысяч с чемто)
хех дык вы его готовить не могётеработает нормульно
там лучше всего гексы юзать если хотите парсить 7 лейер
Отлично.
Народ а кто знает, как редиректить широковещательные пакеты на определенный адрес?Допустим такое правило:
iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT --to-destination 192.168.111.53:137
Вообще должно работать? Есть необходимость пробрасывать некоторые броадкасты на определенный venet-интерфейс.
> Отлично.
> Народ а кто знает, как редиректить широковещательные пакеты на определенный адрес?
> Допустим такое правило:
> iptables -t nat PREROUTING -d 192.168.111.255 -p udp --dport 137 -j DNAT
> --to-destination 192.168.111.53:137
> Вообще должно работать? Есть необходимость пробрасывать некоторые броадкасты на определенный
> venet-интерфейс.вроде должно - проверьте
>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).
>>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 не принимает решения об отсылке пакета нужному хосту. По ходу в арпе какая загвоздка.
> Есть необходимость пробрасывать некоторые броадкасты
> на определенный venet-интерфейс.Хм, а сам venet их умеет? veth-то да...
Уметь-то умеет, но только в если его в мост с физ. интерфейсом положить.Насколько я вкурил iptables, DNAT должен менять поле получателя, т.е. 192.168.111.255:137 на 192.168.111.53:137. Но почитав заморские форумы, понял, что он этого не делает.
Поэтому да, придется бридж громоздить в котором будут лежать veth и eth.
А скажите как редиректить с одного сервера на другой?
То есть у меня два сервера. Один в США, а другой в России. И надо, чтобы при коннекте на порт 80-й к серверу в США шел проброс на 80-й порт в России. Это iptables может? А то я с pf пробовал, спрашивал, так ничего и не получилось.
> Это iptables может?У Вас может получиться или асимметричный NAT, или надо будет его подпирать соответствующей маршрутизацией. IIRC выходит A -> B -> C, C видит пакет с src A и отвечает прямиком на A, но там-то ждут ответ от B.
Ну мне приходилось решать через portfwd или datapipe (datapipe.c). Решение userspace, а хотелось бы на уровне ядра через iptables.
Конечно может. С незапамятных времён.Двойной НАТ спасёт при такой постановке задачи. В одном правиле меняете dst ip (на российский), а потом в другом scr ip (на штатовский). Но надо учитывать, что при таком решении российская машина будет видеть все коннекты как приходящие со штатовской машины, а не с настоящего клиента.
Если вам на российской машине надо отслеживать ip клиента - есть другой вариант: в штатах поставить nginx или Апач как реверс-прокси, и одновременно с пересылкой запроса генерить заголовок X-Forwarded-For. При этом естественно ожидается, что российская сторона умеет обрабатывать этот самый заголовок. Но это уже user-level, а не iptables.
На самом деле вы просто определитесь - а что вам надо: решить определённую задачу или решить определённую задачу средствами iptables.
Двойной НАТ, да, двойной НАТ нужен. Точно. Спасибо.80-й порт я привел для примера. Конечно, nginx очень подходит, если дело касается http/https.
Самое плохое, что в 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.
Казалось бы на переходной период ядро надо сделать более гибким, а они его кастрируют, урезают нужный функционал.
А зачем в IPv6 NAT?
> А зачем в IPv6 NAT?Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать и в других целях (не только из-за отсутствия адресов). Хоть и чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов :)
>> А зачем в IPv6 NAT?
> Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать
> и в других целях (не только из-за отсутствия адресов). Хоть и
> чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов
> :)Например?
>>> А зачем в 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?" =)
или уже появился =)http://netfilter.org/projects/iptables/files/changes-iptable...
> extensions: REDIRECT: add random helpНадо будет еще раз изучить этот вопрос. Но желание всё равно не пропало =)
>>> А зачем в IPv6 NAT?
>> Вы намекаете на избыточность адресного пространства? Иногда NAT требуется использовать
>> и в других целях (не только из-за отсутствия адресов). Хоть и
>> чрезвычайно редко, но, IMHO, НЕ реже, чем повышение TTL проходящих пакетов
>> :)
> Например?Ну, например когда есть сеть, в которой существуют маршрутизаторы, которые не в курсе о всех желаемых маршрутах. Например, эти маршрутизаторы могут быть не в курсе, что за тобой скрывается какая-то другая подсеть, поэтому предётся эту подсеть NAT-ировать. Ведь дело не только в кол-ве адресов, но и в корректно настроеной маршрутизации. Хотя это - далеко не единственная причина.
Иногда мне требуется натирование из диагностических целей. А если говорить про DNAT, то он мне не так давно требовался, чтобы обойти глюк одной програмки. Да и вообще, неужели не очевидно, что как и SNAT, так и DNAT - мягко говоря необходимы, в любом профессиональном фаерволле?
Xaionaro - полностью согласен!
Те кто удалил: NAT - "думали" головой между ног. :(
NAT - был, есть и будет всегда, это аксиома.
Маршрутизацию без: NAT - сделать возможно, но будет
страшный геморой, замешанный на костылях. :(P.S. Для танкистов: попробуйте настроить обмен трафиком
в сети из двух (инет-сервер, рабочая станция) и более
компов, я очень хочу посмотреть на Ваши закипающие моСки.
Или вот еще веселее задача, обмен трафиком между сетями:
инет, диалап, вай-фай, локаль, защищенный периметр.
А теперь что-ить удвоить по числу объектов ....
И на закуску: умножить все, и еще балансировка.