Думаю что абсолютно ничем, модуль conntrack это более продвинутый вариант модуля state.

Можно глянуть в исходниках но мне лень.

у меня есть небольшое подозрение, что модуль conntrack для определения состояния пакета при работе с NAT. Но уверенности нет.

Ты не прав. Оно работает со всеми соединениями что есть в conntrack.

Разница в том, что -m state — эпическая рухлядь, написанная в ту отдаленную эпоху, когда существовали только зачатки системы conntrack.

-m conntrack — более свежая реализация, предоставляющая полноценный доступ ко всем возможностям современного conntrack, включая NAT, таймауты, уточняющий статус (ctstatus) и т.п.

В настоящее время state живет только потому, что оно многократно упоминается в мануалах времен царя Гороха, а также во всяческой копипасте с них.

state чуть-чуть-чуть быстрее работает :) если тебе не нужен функционал conntrack то юзай state.

Спасибо

Ясно. Всем большое спасибо за разъяснения!
Значит будем использовать conntrack/

P.S. [SOLVED]

А как тогда понимать следующее высказывание из Wiki

http://ru.wikipedia.org/wiki/Iptables

state

Идеологический предшественник критерия conntrack. Имеет единственный параметр --state, аналогичный параметру --ctstate критерия conntrack (но, в отличие от него, не поддерживающий состояния DNAT и SNAT).

Долгое время был основным критерием определения состояния, и до сих пор фигурирует во многих руководствах и примерах. Однако в настоящее время разработчики iptables рекомендуют использовать вместо него критерий conntrack. Возможно, что критерий state вообще будет удален из будущих версий iptables/netfilter.

Наличие в conntrack состояний DNAT и SNAT совершенно не означает

что модуль conntrack для определения состояния пакета при работе с NAT

Это связано примерно так же, как молоток (NAT) с микроскопом (conntrack).

Не уловил. Что там, что там - преобразование адресов. Только что в conntrack добавка сканирования потока с вылавливанием сигнатур протоколов.

Поверю на слово википедии, только как не RELATED и не ESTABLISHED правила пройдут NAT? Т.е. у меня сомнения что такое правило вообще необходимо. Ну и у меня iptables не ругается на это правило, поднимать нат чтобы проверить что оно работает лень.

>state чуть-чуть-чуть быстрее работает :) если тебе не нужен функционал conntrack то юзай state.

По-моему, звездеж. Пруф?

Не уловил. Что там, что там - преобразование адресов.

Все операции преобразования адресов регистрируются в системе conntrack. Подробнее в той же википедии, там где про ctorigsrc, ctorigdst и т.п.

Заявление выше про молотки и микроскопы явно исходит от человека, который совсем не в теме. conntrack — один из ключевых компонентов основной системы NAT в Linux. Собственно, без него NAT был бы stateless, как в iproute2.

Вообще о различных применениях conntrack в сетевой подсистеме ядра можно почитать тут

Только что в conntrack добавка сканирования потока с вылавливанием сигнатур протоколов.

Не надо путать систему conntrack и критерий conntrack. state предоставляет такой же интерфейс к той же самой системе conntrack, только куцый и урезанный до невозможности.

>Поверю на слово википедии

Историю правок глянь ;)

только как не RELATED и не ESTABLISHED правила пройдут NAT

Няня, я у них поел!
Какая между ними должна быть связь? Например, DNAT пакет может быть ESTABLISHED, или RELATED, или даже NEW. Параллельно он может быть даже SNAT. Отношение пакета к соединению и факт применения к этому соединению NAT — слегка ортогональные понятия :)

Ступил, я имел в виду snat. snat не пройдёт если нет соотв. записи в коннтраке и нет проброски портов.

зачем пруф ,есть же исходники ;)

>зачем пруф ,есть же исходники ;)

И из этого кода вполне очевидно, что скорость работы будет абсолютно одинаковой =)

Заявление выше про молотки и микроскопы явно исходит от человека, который совсем не в теме. conntrack — один из ключевых компонентов основной системы NAT в Linux. Собственно, без него NAT был бы stateless, как в iproute2.

... conntrack — один из ключевых компонентов основной системы NAT в Linux. ...

Нука человек, который в теме, подумай ка, кто там чьим компонентом является ))).

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

NAT - преобразование адресов. Conntrack - более сложная подсистема (основное назначение - реализация statefull сетевого экрана в Linux). Ну и еще (наверно) через нее же делается NAT.

NAT - преобразование адресов. Conntrack - более сложная подсистема (основное назначение - реализация statefull сетевого экрана в Linux). Ну и еще (наверно) через нее же делается NAT.

Я же говорил, что вы абсолютно не в теме. И ваш ответ наглядно это доказывает :)

Основными функциями conntrack являются:

• stateful-фильтрация. Грубо говоря, присвоение пакетам статусов NEW/ESTABLISHED.
• stateful NAT. Хранение и изменение таких параметров, как orig-src, orig-dst, repl-src и repl-dst, которые в совокупности полностью определяют все возможные операции NAT для данного соединения.
• Сопровождение меток соединений (ctmark), которые позволяют использовать stateful-подход даже в таких stateless by design системах, как QoS (tc filter) и роутинг (ip rule).
• Сбор статистики по соединениям (количество переданных пакетов и байт в обоих направлениях).

Без системы conntrack весь NAT, который делается через netfilter, можно выкинуть на помойку. От него останутся только жалкие огрызки.
Ну и stateless NAT через iproute2, который используют только извращенцы.

... Если из микроскопа выкинуть молоток... Стоп, а почему ваш микроскоп сделан из молотка, двух линз и лейкопластыря?

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

>Основными функциями conntrack являются...

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

conntrack предоставляет большой набор инструментов. И все они используются по своему прямому назначению.

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

... Если из микроскопа выкинуть молоток... Стоп, а почему ваш микроскоп сделан из молотка, двух линз и лейкопластыря?

Вы заменили «назначение» на «составляющее». NAT - задача которую выполняет netfilter, забивание гвоздей (молоток) - задача которую можно выполнять микроскопом. Всё логично. То есть NAT, с этой точки зрения, не часть Conntrac. Он является его расширением.

Мы ведь спорим про одно и то же, ваши «Основные функции» описывают функционал statefull-фаерволла, то есть как я и сказал, его

основное назначение - реализация statefull сетевого экрана в Linux

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

Я всё же остаюсь при мнении, что данное сравнение вполне справедливо.

>Вы заменили «назначение» на «составляющее». NAT - задача которую выполняет netfilter, забивание гвоздей (молоток) - задача которую можно выполнять микроскопом. Всё логично. То есть NAT, с этой точки зрения, не часть Conntrac. Он является его расширением.

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

основное назначение - реализация statefull сетевого экрана в Linux

Если уж на то пошло, основное назначение conntrack — сопровождение таблиц состояний.

Считать, что conntrack предназначена только для stateful-фильтрации, а остальное просто прибамбасы — распространенное заблуждение дилетантов. Ну что ж, полноценное понимание и использование возможностей netfilter+conntrack в ближайшем будущем им не грозит.

conntrack предоставляет большой набор инструментов. И все они используются по своему прямому назначению.

Гм, а вот с этим я не спорю, конечно.

Изначально мое несогласие было вызвано, тем что

у меня есть небольшое подозрение, что модуль conntrack для определения состояния пакета при работе с NAT. Но уверенности нет.

В общем наверно молоток/микроскоп здесь всё таки не совсем удачно, я хотел сказать лишь что conntrack это не только NAT.

Хотя похоже что я ошибся еще и в интерпретации того что хотел сказать Atlant... Если исправить фразу на

у меня есть небольшое подозрение, что модуль conntrack используется для определения состояния пакета при работе с NAT.

То всё верно.

Считать, что conntrack предназначена только для stateful-фильтрации, а остальное просто прибамбасы — распространенное заблуждение дилетантов. Ну что ж, полноценное понимание и использование возможностей netfilter+conntrack в ближайшем будущем им не грозит.

Ну да, но еще можно считать что сетевой фильтр это не только stateful-фильтрация, но и

* stateful NAT. Хранение и изменение таких параметров, как orig-src, orig-dst, repl-src и repl-dst, которые в совокупности полностью определяют все возможные операции NAT для данного соединения. * Сопровождение меток соединений (ctmark), которые позволяют использовать stateful-подход даже в таких stateless by design системах, как QoS (tc filter) и роутинг (ip rule). * Сбор статистики по соединениям (количество переданных пакетов и байт в обоих направлениях).

А в моем дипломе сетевой фильтр (Untangle 7.0 (комментарий) будет еще к тому же включать в себя иерархию пользователей, биллинг и веб-интерфейс.

но и

• stateful NAT. Хранение и изменение таких параметров, как orig-src, orig-dst, repl-src и repl-dst, которые в совокупности полностью определяют все возможные операции NAT для данного соединения.
• Сопровождение меток соединений (ctmark), которые позволяют использовать stateful-подход даже в таких stateless by design системах, как QoS (tc filter) и роутинг (ip rule).
• Сбор статистики по соединениям (количество переданных пакетов и байт в обоих направлениях).

/fixed

В общем наверно молоток/микроскоп здесь всё таки не совсем удачно, я хотел сказать лишь что conntrack это не только NAT.

Отлично, значит, мы все-таки пришли к консенсусу :)

А в моем дипломе сетевой фильтр (Untangle 7.0 (комментарий) будет еще к тому же включать в себя иерархию пользователей, биллинг и веб-интерфейс.

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

Насчет критерия quota — советую глянуть connbytes и quota2.
Насчет ulogd2 — а что, его таки допилили? В гите тишина уже четыре месяца, на офсайте он до сих пор значится как недопиленный.
Ну и насчет юзеров — вы уже ковыряли NuFW и NuLog?

Вообще о методах сбора статистики рекомендую глянуть доклад Гарольда Велта (участник и бывший председатель Netfilter Core Team) с Linux Symposium 2005. Что характерно, за последние пять лет существенных изменений на данном фронте не произошло.

Насчет юзеров - мой разум не приемлет этот велосипед из NuFW, помоему достаточно идентификации по IP адресу после аутентификации через Web-интерфейс. Ну или как более надежный вариант - аутентификация через PPTP и далее опять же идентификация по IP.

За доклад спасибо, жалко что он не попался мне год-полтора назад %).

От ulogd2 решил отказаться, действительно думал что допилят, но вообще мне его функционал не нужен, решил всё через django делать. А реализовать свой парсер сообщений от conntrack'а не так уж сложно - nfct_callback_register и парсинг XML полученного nfct_snprintf. Парсинг XML конечно смущает, может быть существует и другой способ. Но думаю это не будет сильно нагружать систему по сравнению с работой базы данных, особенно если учесть что у меня всё через Django :-). После сессии начну писать.

Connbytes думаю не понадобится, а quota2 может быть и буду использовать, хотя уже продумал систему правил по которой подойдет quota.

Ulogd2 не нужен

http://www.linux.org.ru/jump-message.jsp?msgid=4451063&cid=4451153

Это расширение функционала pynetfilter_conntrack механизмом событий?

Кстати, в гите ulogd2 несколько часов назад ВНЕЗАПНО началось активное шевеление. Они испугались? :)

Это расширение функционала pynetfilter_conntrack механизмом событий?

Не, это просто нормальная реализация именно механизма событий для питона. Мне вообще не нравится как написаны python-netfilter (от Bolore telecom) и pynetfilter_conntrack (от INL Software). В первом какая-то хрень вместо интерфейса, не понятно что откуда импортировать чтобы было правильно, это не Python-way (не, конечно пользоваться можно, но неплохо было бы его переписать). В pynetfilter_conntrack тоже не всё логично сделано, об этом свидетельствует хотя бы то, что разработчик не смог добавить механизм событий когда это потребовалось... Ну или я просто неосилятор и не смог разобраться что же он там хотел сделать...

Кстати, в гите ulogd2 несколько часов назад ВНЕЗАПНО началось активное шевеление. Они испугались? :)

Магия какая-то )