Нужна ли цепочка INPUT nat table?
В страница руководства 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, который находится между mangle / INPUT и фильтр / ВХОД. Посмотрите в конце на вероятную причину, по которой он отсутствует на схеме.
nat / PREROUTING будет применяться до первоначального решения о маршрутизации, для все случаи (маршрутизируемый или для трафика локальной конечной точки), nat / INPUT произойдет после первоначального решения о маршрутизации, только если трафик считается локальным.
Как это реализовано в отношении маршрутизации и отслеживания соединений до маршрутизации, с nat / PREROUTING, вы можете изменить то, что повлияет на маршрутизацию: пункт назначения (-j DNAT), но не происхождение. После маршрутизации с nat / INPUT, это наоборот: вы не можете изменить пункт назначения, но можете изменить исходную (-j SNAT).
У вас есть некоторая перевернутая симметрия с нат / ВЫХОД (который находится на схеме) и nat / POSTROUTING: нат / ВЫХОД предназначен только для локально инициированного трафика и может изменить решение о маршрутизации, как в nat / PREROUTING, таким образом, можно изменить пункт назначения (с -j DNAT), второй - для всего трафика, маршрутизированного или локально инициированного, после того, как любое решение о маршрутизации уже было принято (и может изменить источник, например nat / INPUT с участием -j SNAT).
Чтобы ответить на вопрос, nat / INPUT не существовало до тех пор, пока в нем не было необходимости. Он был специально создан для обработки новых возникающих случаев, избегая использования пространств имен, но используя зоны conntrack вместо. Появился в 2010 году.. Эта ссылка включает примеры использования, мотивирующие ее создание, но ее довольно сложно понять, поскольку она использует зоны conntrack (которые позволяют разделять полностью идентичные потоки (тот же протокол из 5 кортежей, saddr, sport, daddr, dport) в разные записи conntrack, добавляя тег зоны на них. Например, для трафика с маршрутизацией по специальной политике один из eth0 собирается eth2, другой прибывает из eth1 собирается eth3, или как в первой ссылке, чтобы закольцевать трафик и отслеживать / натирать его отдельно).