Назад | Перейти на главную страницу

Когда модуль conntrack iptable отслеживает состояние пакетов?

Сначала необходимо сохранить состояния. С каким-то старым брандмауэром BSD, который я использовал, я полагаю, назывался IPFW, я использовал правило, которое насыщало «отслеживать состояние уходящего пакета», и это было помещено в исходящее направление интерфейсов. Затем другое правило для входящего направления, которое проверяет их на соответствие тем состояниям, которые были созданы правилом для исходящего направления. Таким образом, раньше было 2 правила: (1) для заполнения таблицы состояний, это было в исходящем направлении, и (2) для поиска в таблице состояний, это было в входящем направлении.

Но с connntrack я вижу, что он применяется к цепочке INPUT, например, это правило:

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

Это заставляет меня задаться вопросом, что на самом деле делает это утверждение?

Вводная презентация Netfilter и conntrack

Сначала обязательная схема потока пакетов в Netfilter и General Networking:

Netfilter - это структура фильтрации пакетов, которая вставляется поверх остальной части сетевого стека (представленной «решением о маршрутизации» и другими частями белого квадрата с закругленными краями). Netfilter предоставляет хуки и API для других подсистем и «клиентов». Среди этих частей Conntrack (трекер подключений) и iptables (или столы). Разделение Netfilter и Conntrack довольно нечетко. Вы можете просто рассмотреть Conntrack как составная часть Netfilter.

На схеме, описывающей различные шаги, которые проходит пакет, вы можете видеть, что в какой-то момент (между raw / PREROUTING и mangle / PREROUTING, или между raw / OUTPUT и mangle / OUTPUT) пакет проходит Conntrack.

С этой точки зрения, Conntrack будет искать в собственных таблицах поиска (мини-база данных поиска, хранящаяся в памяти ядра):

  • если характеристики этого пакета не найдены (и если не объявлено UNTRACKED в необработанной таблице), новый двунаправленный conntrack кортеж запись (протокол, затем информация о конкретном семействе и протоколе: начальный источник и порт, начальное назначение и порт, источник и порт ответа, место назначения и порт ответа (последние два обычно являются обратными, если не задействованы NAT или какие-то странные протоколы, такие как echo ответ на соответствующий эхо-запрос для ICMP)), описывающий поток, создается с состоянием NEW.
  • если он соответствует (в любом направлении) предыдущей записи и совместим с состоянием этого потока, состояние потока может быть изменено (например: изменение с NEW на ESTABLISHED, если этого не было раньше).
  • если по какой-то конкретной причине пакет не может соответствовать существующему потоку, несмотря на то, что он имеет свои характеристики (например: поздний пакет TCP, полученный после успешной повторной передачи, поэтому он находится вне окна в отношении последовательности и значений SACK), пакет будет помечен как НЕДЕЙСТВИТЕЛЬНЫЙ.
  • есть несколько других случаев, таких как RELATED: речь идет о пакетах, не являющихся частью самого потока, но связанных с новым потоком, который может быть связан с другим существующим (например, в базе данных) потоком. Два примера: ошибка ICMP, созданная при получении пакета (например: порт UDP недоступен) или когда специальный помощник протокола, такой как модуль ядра nf_conntrack_ftp , который является плагином к Conntrack подсистема, обнаруживает, что пакет является частью отдельного потока данных, связанного с командами FTP PASV / EPSV или PORT / EPRT, выполняемыми в потоке команд (на порту 21).

Решение вопроса

Все это, как говорится, вот ответы на две ваши пули:

  • в основном сетевом пространстве имен Conntrack начинает отслеживать соединения, как только его модули (включая возможные соответствующие подмодули, специфичные для протокола) загружаются. Для не начальных сетевых пространств имен (контейнеров ...) это также требует, чтобы на них ссылалась какая-то другая подсистема (например, OP iptablesмодуля conntrack или однократно используя команду conntrack описано позже). Это значение по умолчанию, и пакет должен быть специально помечен как UNTRACKED. перед в Conntrack подсистема видит это для того, чтобы этот пакет не отслеживался. В Linux есть только несколько случаев, когда не требуется отслеживание, но тогда, конечно, брандмауэр с отслеживанием состояния и динамический / динамический NAT с сохранением состояния больше не будут доступны (скрытый NAT, который может даже потребовать использования UNTRACKED в первую очередь, все еще может сделано, но не с iptables. tc или столы жестяная банка). Избегать Conntrack обработка некоторых пакетов, такого рода iptables можно использовать правило (например: порт 80 / tcp):

    iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack

  • Когда пакет проходит filter / INPUT и достигает этого правила:

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

    В iptablesспецифический модуль ядра xt_conntrack запрашивает Conntrack подсистема (обрабатывается различными соответствующими модулями ядра nf_conntrack*) и спрашивает о состоянии этого пакета в его базе данных поиска. Если ответ RELATED или ESTABLISHED пакет соответствует и переходит к вердикту ACCEPT. Собственно результат уже есть кешируется в пакет при первом поиске (обычно Conntrack) так что это дешевый "поиск". Таким образом, это общее правило для обработки уже принятых ранее потоков. Эти потоки могут быть изначально приняты в правилах, явно упоминающих -m conntrack --ctstate NEW или просто правила, не упоминающие об этом, но размещенные после это общее правило (но помните о состоянии INVALID, которое обычно следует отбрасывать перед этим).

  • добавление маркера: обработка входящих и исходящих пакетов довольно симметрична между PREROUTING и OUTPUT (даже если они не выглядят симметрично): Conntrack интерфейсов в PREROUTING, а также в OUTPUT (и в некоторых других местах, учитывая NAT работает с Conntrack, кроме первого пакета в состоянии NEW traversing iptablesнат таблица). Это может немного отличаться от описания, которое вы написали о IPFW. Если сервер, на котором запущены приложения, также ограничивает исходящие потоки, то ему, скорее всего, понадобится тот же общий iptables правило как в filter / OUTPUT, так и в filter / INPUT, чтобы разрешить прохождение исходящих ответных пакетов уже принятого входящего трафика.

Дополнительная информация

Есть специальные инструменты для взаимодействия с Conntrack таблицы поиска подсистемы из Conntrack-Tools.

  • conntrack: для запроса, удаления или обновления содержимого таблиц поиска, обрабатываемых Conntrack.

    Некоторые примеры.

    Вы можете перечислить все отслеживаемые записи (которые могут быть большими без дополнительного фильтра) с помощью:

    conntrack -L

    Если ваша система выполняет NAT (например, маршрутизатор перед частной LAN или запускает виртуальные машины и контейнеры), вы можете использовать --any-nat, --src-nat или --dst-nat только отображать соотв. весь NAT, весь NAT источника (маскарадный) или весь NAT назначения (обычно для перенаправленных портов):

    Мониторинг в реальном времени Conntrack События:

    conntrack -E

  • conntrackd: демон, двумя основными целями которого являются (conntrack) учет потоков и статистика, или кластер межсетевого экрана высокой доступности с отслеживанием состояния синхронизация состояний.

Отслеживание соединений - это отдельная функция Netfilter, и она не настраивается с помощью IPTables.

На картинке два conntrack шаги в пути INPUT и один в пути OUTPUT. Эти шаги связывают отдельные пакеты с существующими соединениями, отслеживаемыми в таблице отслеживания соединений, или создают новые записи отслеживания соединений в таблице.

Функциональность Conntrack - это модуль ядра Linux, и он часто включается в ядро ​​в конфигурации по умолчанию.

Работу Conntrack можно настроить, отрегулировав net.netfilter.nf_conntrack sysctl значения.

Ваша вторая альтернатива - это то, что происходит. Информация о состоянии записывается функцией Conntrack, а правило IPTables просто обращается к таблице Conntrack за информацией.