Есть ли необходимость в цепочке INPUT таблицы nat?

Страница руководства iptables предлагает следующие стандартные таблицы и цепочки:

                raw     mangle  nat     filter
PREROUTING       X       X       X       
INPUT                    X       X       X
FORWARD                  X               X
OUTPUT           X       X       X       X
POSTROUTING              X       X

Но диаграмма на википедийной странице iptables не указывает на использование цепочки nat INPUT. Я знаю, что диаграмма является упрощением, поскольку, например, они намеренно опускают таблицу безопасности. Это может быть педантичный вопрос, поскольку я пытаюсь самостоятельно изучить брандмауэры, но ответ может быть интересен.

ОБНОВЛЕНИЕ: исправьте порядок nat/INPUT.

Схема изначально не включала nat/INPUT, но я неправильно написал, что она была перед filter/INPUT, и эта схема (неправильно) была обновлена позже с этой цепочкой между mangle/INPUT и filter/INPUT, что оказалось неверным.

nat/INPUT срабатывает после filter/INPUT.

Поскольку тип nat является специальным и связан с conntrack, оказывается, что приоритет nftables даже не зависит от приоритета хуков, что для nat влияет только на приоритеты между несколькими цепочками внутри одного и того же nat хука. Использование nftables вместо iptables не может изменить это, изменив приоритет на значение ниже, чем 0 для filter/INPUT или -150 для mangle/INPUT: он всегда срабатывает точно на 100. (Тот же поведение с nat/PREROUTING: он всегда срабатывает точно на -100 для PREROUTING, даже если задавать приоритет цепочки -199). Все это можно проверить, используя iptables‘ -j TRACE или nftables‘ meta nftrace set 1 и наблюдая за последовательностью проходящих цепочек. Тесты проводились на ядре 5.13.x, специфическое поведение по этому поводу может измениться в будущем. iptables даже не имея возможности изменить эти приоритеты все равно не имеет выбора.

Как написал @Эндрю Бейт, правильная схема, отображающая правильный порядок, может быть найдена здесь с текущим изображением:

Что касается вопроса…

nat/PREROUTING будет применяться перед первоначальным решением маршрутизации, для всех случаев (маршрутный или для локального трафика), nat/INPUT произойдет после первоначального решения маршрутизации, только если трафик считается локальным.

Таким образом, реализовано в отношении маршрутизации и отслеживания соединений перед маршрутизацией, с nat/PREROUTING, вам разрешается изменять то, что повлияет на маршрутизацию: назначение (-j DNAT), но не источник. После маршрутизации, с nat/INPUT, это наоборот: вы не можете изменить назначение, но можете изменить источник (-j SNAT).

У вас есть определенная инвертированная симметрия с nat/OUTPUT (которая на схеме) и nat/POSTROUTING: nat/OUTPUT предназначен только для локально инициированного трафика и может изменять решение маршрутизации, как в nat/PREROUTING, тем самым может изменять назначение (с -j DNAT), второй предназначен для всего трафика, маршрутизируемого или локально инициированного, после того, как любое решение маршрутизации уже было принято (и может изменять источник, как nat/INPUT, с -j SNAT).

Отвечая на вопрос, nat/INPUT не существовал, пока не возникла необходимость. Он был специально создан для обработки новых возникающих случаев, избегая необходимости в пространстве имен, но используя зоны conntrack вместо этого. Он появился в 2010 году. Эта ссылка включает примеры использования, которые мотивировали его создание, но их довольно трудно понять, поскольку они используют зоны conntrack (которые позволяют разделять абсолютно идентичные потоки (одинаковые 5-тугли протокола, saddr, sport, daddr, dport) на разные записи conntrack, добавляя на них тег зоны. Например, для специального маршрута полисного трафика, один приходит с eth0 и идет на eth2, другой приходит с eth1 и идет на eth3, или, как в первой ссылке, для возвратного трафика и его отслеживания/nat отдельно).