Сначала ему нужно сохранить состояния. С каким-то старым брандмауэром BSD, который я использовал, кажется, он назывался IPFW, я обычно устанавливал правило, которое устанавливало "отслеживать состояние исходящего пакета", и оно устанавливалось на исходящем направлении интерфейсов. Затем еще одно правило на входящем направлении, которое проверяло их на соответствие тем состояниям, которые были созданы правилом на исходящем направлении. Так что раньше было 2 правила: (1) для заполнения таблицы состояний, это было на исходящем направлении, и (2) для поиска в таблице состояний, это было на входящем направлении.
Но с connntrack я вижу, как это применяется к цепочке INPUT, например, как это правило:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Это заставляет меня задуматься: что на самом деле делает это утверждение?
- Означает ли это, что он начнет отслеживать пакеты, соответствующие этому правилу, помещая их информацию в таблицу состояний?
- Или он говорит, что у него уже есть информация о состояниях, и он собирается действовать против входящих сообщений на ее основе? (например, принимать, если они принадлежали ранее принятому соединению?). Но, в этом случае, где была заполнена таблица состояний? Какое правило это делает? Или она не имеет правил и неявная?
решение1
Вводная презентация Netfilter и conntrack
Сначала обязательная схема потока пакетов в Netfilter и общих сетевых технологиях:
Netfilter — это фреймворк фильтрации пакетов, который вставляется поверх остальной части сетевого стека (представленного «решением о маршрутизации» и другими белыми закругленными частями). Netfilter предоставляет хуки и API для других подсистем и «клиентов». Среди этих частей:conntrack(трекер подключений) иiptables(илиnftables). Разделение между Netfilter иconntrackдовольно размыто. Вы можете просто рассмотретьconntrackкак интегрированная часть Netfilter.
На схеме, описывающей различные этапы прохождения пакета, вы можете увидеть, что в какой-то момент (между raw/PREROUTING и mangle/PREROUTING или между raw/OUTPUT и mangle/OUTPUT) пакет проходитconntrack.
В этот момент,conntrackбудет выполнять поиск в собственных таблицах поиска (мини-база данных поиска, хранящаяся в памяти ядра):
- если характеристики этого пакета не найдены (и если он не объявлен как UNTRACKED в таблице raw), новый conntrack двунаправленныйкортежзапись (протокол, затем конкретная информация о семействе и протоколе: начальный источник и порт, начальный пункт назначения и порт, источник и порт ответа, пункт назначения и порт ответа (последние два обычно обратны, если только не задействованы NAT или какие-то странные протоколы, например, эхо-ответ, соответствующий эхо-запросу для ICMP)), описывающая поток, создается с состоянием NEW.
- если он совпадает (в любом направлении) с предыдущей записью и совместим с состоянием этого потока, состояние потока может быть изменено (например: изменено с NEW на ESTABLISHED, если ранее это не было так).
- Если по какой-то определенной причине пакет не может соответствовать существующему потоку, несмотря на его характеристики (например, запоздалый пакет TCP, полученный после успешной повторной передачи, и, следовательно, выходящий за пределы окна с точки зрения последовательности и значений SACK), пакет будет помечен как НЕДОПУСТИМЫЙ.
- есть несколько других случаев, таких как RELATED: это касается пакетов, не являющихся частью самого потока, но связанных с новым потоком, который может быть связан с другим существующим (например, в базе данных) потоком. Два примера — это ошибка ICMP, созданная при получении пакета (например, порт UDP недоступен) или когда специальный помощник протокола, такой как модуль ядра
nf_conntrack_ftp, который является плагином кconntrackПодсистема определяет, что пакет является частью отдельного потока данных, связанного с командами FTP PASV/EPSV или PORT/EPRT, выполняемыми в потоке команд (на порту 21).
Обращаясь к вопросу
Учитывая все вышесказанное, вот ответы на ваши два вопроса:
в основном сетевом пространстве именconntrackначинает отслеживать соединения, как только его модули (включая возможные соответствующие подмодули, специфичные для протокола) загружены. Для неначальных сетевых пространств имен (контейнеров...) это также требует, чтобы какая-то другая подсистема ссылалась на него (например, OP'siptables(модуль conntrack или с помощью команды,
conntrackописанной ниже). Это значение по умолчанию, и пакет должен быть специально помечен как НЕОТСЛЕЖИВАЕМЫЙдо the conntrackподсистема видит, что этот пакет не отслеживается. В Linux есть только несколько случаев, когда не требуется отслеживание, но тогда, конечно, брандмауэр с отслеживанием состояния и динамический NAT с отслеживанием состояния больше не будут доступны (NAT без отслеживания, который может даже потребовать использования UNTRACKED в первую очередь, все еще может быть реализован, но не сiptables.ткилиnftablesможет). Чтобы избежать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Когда пакет проходит через фильтр/INPUT и достигает этого правила:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTTheiptablesконкретный модуль ядра
xt_conntrackзапрашиваетconntrackподсистема (обрабатываемая различными соответствующими модулями ядраnf_conntrack*) и спрашивает о состоянии этого пакета в своей базе данных поиска. Если ответRELATEDилиESTABLISHEDпакет соответствует и переходит к вердикту ACCEPT. Фактически результат ужекэшировано впакетпервый раз, когда поиск был сделан (обычноconntrack) так что это дешевый "поиск". Таким образом, это общее правило для обработки потоков, уже принятых ранее. Эти потоки могут быть изначально приняты в правилах, явно упоминающих-m conntrack --ctstate NEWили просто не упоминающих их, но помещенныхпослеэто общее правило (но помните о состоянии INVALID, которое обычно следует DROP перед этим).добавляем маркер: обработка входящих и исходящих пакетов между PREROUTING и OUTPUT довольно симметрична (даже если они не выглядят симметричными):conntrackинтерфейсы в PREROUTING, а также в OUTPUT (и в нескольких других местах, учитываяНАТработает сconntrack, за исключением его первого пакета в состоянии NEW, проходящегоiptables's nat table). Это может немного отличаться от описания, которое вы написали о IPFW. Если сервер, на котором запущены приложения, также ограничивает исходящие потоки, то ему, скорее всего, нужен тот же самый общийiptablesправило как в filter/OUTPUT, так и в filter/INPUT, чтобы разрешить прохождение исходящих ответных пакетов уже принятого входящего трафика.
Дополнительная информация
Существуют специальные инструменты для взаимодействия сconntrackтаблицы подсистемы поиска изconntrack-инструменты.
conntrack: для запроса, удаления или обновления содержимого таблиц поиска, обрабатываемыхconntrack.Некоторые примеры.
Вы можете вывести список всех отслеживаемых записей (которые могут быть большими без дополнительного фильтра) с помощью:
conntrack -LЕсли ваша система выполняет NAT (например, маршрутизатор перед частной локальной сетью или работающие виртуальные машины и контейнеры), вы можете использовать
--any-nat,--src-natили--dst-nat, чтобы отобразить только все NAT, все исходные NAT (маскарад) или все целевые NAT (обычно для перенаправленных портов):Мониторинг в реальном времениconntrackсобытия:
conntrack -Econntrackd: демон, двумя основными целями которого являются (conntrack) учет и статистика потока, иликластер брандмауэров с отслеживанием состояния высокой доступностисинхронизация состояний.
решение2
Отслеживание подключений — это отдельная функция Netfilter, и она не настраивается с помощью IPTables.
На рисунке показаны два conntrackшага на пути INPUT и один на пути OUTPUT. Эти шаги связывают отдельные пакеты с существующими соединениями, отслеживаемыми в таблице отслеживания соединений, или создают новые записи отслеживания соединений в таблице.
Функциональность Conntrack представляет собой модуль ядра Linux и часто включается в ядро в конфигурации по умолчанию.
Работу Conntrack можно настроить, изменив net.netfilter.nf_conntrackзначения sysctl.
Ваша вторая альтернатива — вот что происходит. Информация о состоянии записывается функцией Conntrack, а правило IPTables просто обращается к таблице Conntrack за информацией.