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