В чем разница между -m conntrack --ctstate и -m state --state

Я читаю это Howto, и есть что-то вроде этого:

Мы можем разрешить установленным сеансам получать трафик:

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Приведенное выше правило не имеет пробелов по обе стороны от запятой в ESTABLISHED, RELATED

Если приведенная выше строка не работает, возможно, вы используете кастрированный VPS, поставщик которого не предоставил расширение, и в этом случае в качестве крайней меры можно использовать более низкую версию:

$ sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Есть ли значительная разница в работе между -m conntrack --ctstateи -m state --state? Они говорят, что можно не работать, но они не говорят, почему. Почему я должен предпочесть одно другому?

Я не претендую на звание эксперта по iptablesправилам, но первая команда использует расширение отслеживания соединений ( conntrack), а вторая использует stateрасширение.

Точка данных № 1

Согласно этому документуconntrack расширение вытеснены state.

 Obsolete extensions:
  • -m state: replaced by -m conntrack

Точка данных № 2

Тем не менее, я нашел этот SF Q & A под названием: Вопросы брандмауэра о состоянии и политике? где ФП заявил, что задал этот вопрос на IRC в # iptables @ freenode. Обсудив это, он пришел к выводу, что:

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

Точка данных № 3

Наконец, я нашел этот SF Q & A под названием: Iptables, в чем разница между -m state и -m conntrack? , Ответ на этот вопрос, вероятно, является лучшим доказательством и советом о том, как рассматривать использование conntrackи state.

выдержка

Оба используют одинаковые внутренние компоненты ядра (подсистема отслеживания соединений).

Заголовок файла xt_conntrack.c:

xt_conntrack - Netfilter module to match connection tracking
information. (Superset of Rusty's minimalistic state match.)

Поэтому я бы сказал - модуль состояний проще (и, возможно, менее подвержен ошибкам). Это также больше в ядре. Conntrack с другой стороны имеет больше опций и возможностей _[1] .

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

• Подобный вопрос на netfilter maillist.

[1] Очень полезно, например, "-m conntrack --ctstate DNAT -j MASQUERADE" исправление маршрутизации / DNAT ;-)

Точка данных № 4

Я нашел эту ветку в обсуждениях netfilter@vger.kernel.org netfilte / iptables под названием: сопоставление состояний устарело в версии 1.4.17 , которая говорит, что stateэто просто псевдоним, conntrackпоэтому не имеет значения, какой вы используете, в оба обстоятельства вы используете conntrack.

выдержка

На самом деле, я должен согласиться. Почему мы не сохраняем «состояние» как псевдоним и не принимаем старый синтаксис в «conntrack»?

состояние в настоящее время является псевдонимом и преобразуется в conntrack в iptables, если оно есть в ядре. Сценарии не сломаны.

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

Псевдоним уже сделан в пользовательском пространстве. Один из них вводит «state», и он преобразуется в «conntrack», а затем отправляется ядру. (Итак, насколько я вижу, если псевдонимы модулей ipt_state и т. Д. Были добавлены в модуль conntrack, даже модуль ядра состояния может быть удален.)

Рекомендации

• Вопросы по брандмауэру о состоянии и политике?
• iptables: различия с использованием conntrack или модуля состояния

Я не эксперт по netfilter, но я заглянул в man-страницу iptables-extension и удивился, вот она

The "state" extension is a subset of the "conntrack" module.

Таким образом, state является частью conntrack и просто его более простой версией, если вам действительно нужно - состояние, а не более причудливые функции conntrack.