Почему ни один пакет не проходит через цепочку nat в хуке output или postrouting с этим набором правил?

У меня есть машина с сетевым интерфейсом enp0s3, которому назначен IPv4 адрес 192.168.20.254. Кроме того, на другой машине работает DNS-сервер, слушающий на IPv4 адресе 192.168.20.10. Сеть между двумя машинами работает без проблем, машины могут достигать друг друга. На обеих машинах IPv6 полностью отключен через параметр ядра ipv6.disable=1.

На первой машине у меня следующие правила nftables:

root@charon /etc/network # nft list ruleset
table ip t_IP {
        chain output-route {
                type route hook output priority mangle; policy accept;
                ip daddr 192.168.20.10 meta nftrace set 1
        }

        chain output-filter {
                type filter hook output priority filter; policy accept;
                ip daddr 192.168.20.10 meta nftrace set 1
        }

        chain output-nat {
                type nat hook output priority 100; policy accept;
                ip daddr 192.168.20.10 meta nftrace set 1
        }

        chain postrouting-filter {
                type filter hook postrouting priority filter; policy accept;
                ip daddr 192.168.20.10 meta nftrace set 1
        }

        chain postrouting-nat {
                type nat hook postrouting priority srcnat; policy accept;
                ip daddr 192.168.20.10 meta nftrace set 1
        }
}

Цель этого набора правил – принимать все пакеты независимо от чего-либо, а также иметь возможность отслеживать все пакеты, которые исходят с машины через все цепочки в пути выхода пакетов.

Я поставил meta nftrace set 1 в каждую цепочку, потому что не знаю, какая из них будет первой, через которую пройдут пакеты. Чтобы избежать излишнего шума, трассировка включена только для DNS пакетов (которые здесь легко идентифицируются либо по их IP-адресу назначения, либо по порту назначения; вышеуказанный набор правил делает первое).

nft monitor trace показывает следующий вывод, когда я ввожу host blahblah во втором терминале на машине (я вставил пустую строку, чтобы добавить немного структуры):

trace id b00605cc ip t_IP output-route packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 8386 ip length 67 udp sport 37348 udp dport 53 udp length 47 @th,64,96 0x69ea01000001000000000000
trace id b00605cc ip t_IP output-route rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id b00605cc ip t_IP output-route verdict continue
trace id b00605cc ip t_IP output-route policy accept
trace id b00605cc ip t_IP output-filter packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 8386 ip length 67 udp sport 37348 udp dport 53 udp length 47 @th,64,96 0x69ea01000001000000000000
trace id b00605cc ip t_IP output-filter rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id b00605cc ip t_IP output-filter verdict continue
trace id b00605cc ip t_IP output-filter policy accept
trace id b00605cc ip t_IP postrouting-filter packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 8386 ip length 67 udp sport 37348 udp dport 53 udp length 47 @th,64,96 0x69ea01000001000000000000
trace id b00605cc ip t_IP postrouting-filter rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id b00605cc ip t_IP postrouting-filter verdict continue
trace id b00605cc ip t_IP postrouting-filter policy accept

trace id 4e72ea91 ip t_IP output-route packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 42220 ip length 50 udp sport 44559 udp dport 53 udp length 30 @th,64,96 0x395901000001000000000000
trace id 4e72ea91 ip t_IP output-route rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id 4e72ea91 ip t_IP output-route verdict continue
trace id 4e72ea91 ip t_IP output-route policy accept
trace id 4e72ea91 ip t_IP output-filter packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 42220 ip length 50 udp sport 44559 udp dport 53 udp length 30 @th,64,96 0x395901000001000000000000
trace id 4e72ea91 ip t_IP output-filter rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id 4e72ea91 ip t_IP output-filter verdict continue
trace id 4e72ea91 ip t_IP output-filter policy accept
trace id 4e72ea91 ip t_IP postrouting-filter packet: oif "enp0s3" ip saddr 192.168.20.254 ip daddr 192.168.20.10 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 42220 ip length 50 udp sport 44559 udp dport 53 udp length 30 @th,64,96 0x395901000001000000000000
trace id 4e72ea91 ip t_IP postrouting-filter rule ip daddr 192.168.20.10 meta nftrace set 1 (verdict continue)
trace id 4e72ea91 ip t_IP postrouting-filter verdict continue
trace id 4e72ea91 ip t_IP postrouting-filter policy accept

Трассировка показывает, как два разных пакета проходят через цепочки. Оба пакета – это типичные DNS-клиенты, которые исходят с локальной машины (192.168.20.254, случайный непривилегированный исходный порт) и идут к DNS-серверу (192.168.20.10, порт назначения 53).

Каждый пакет сначала достигает выхода. На этом этапе он сначала проходит через цепочку route, затем через цепочку filter, в соответствии с приоритетами, на которых они зарегистрированы.

Но никакой пакет никогда не проходит через цепочку nat на output. Почему это не происходит?

Аналогично, каждый пакет, после выхода из output, достигает postrouting и проходит через цепочку filter, которая там зарегистрирована. Но никакой пакет никогда не проходит через цепочку nat, которая также зарегистрирована на postrouting. Почему это снова не происходит?

Документация (в разделе “Verdict Statement”) говорит, что вердикт accept для пакета останавливает оценку дальнейших правил в текущей цепочке, но что пакет, тем не менее, проходит через более поздние цепочки, которые зарегистрированы на том же хоке, и все цепочки на более поздних хоках, пока он не встретит другой вердикт, который действительно окончателен, например, вердикт drop. Это означает, что вердикт accept является окончательным только в пределах цепочки, но не для всего хока или глобального охвата. В отличие от этого, вердикт drop является окончательным и немедленно прекращает любую дальнейшую оценку.

Поскольку каждая цепочка в вышеуказанном наборе правил имеет политику accept и неявных вердиктов, по крайней мере первый пакет каждого соединения должен проходить через цепочки nat на хоке output или postrouting. Но это не так.

Что я упускаю?

NAT – Аллегория

Итак, я написал историю, похожую на эту, на AskUbuntu давно, и она нуждается в обновлении. Я надеюсь, что эта словесная иллюстрация поможет автору вопроса и другим понять, как работает NAT. Как сказал автор вопроса, никакие пакеты не путешествуют по его цепочке NAT, потому что трафик внутри локальной сети, и NAT не нужен. Надеюсь, эта история поможет понять почему.

Фотография выше поможет объяснить NAT и принцип демаркации.

• Представьте, что все туристы внутри стен этого замка – это устройства в вашей сети.
• Мы предположим, что у этого замка есть подъемный мост, и он опущен (это была лучшая изображение, которое я смог найти с обеими сторонами – внутренней и внешней).
• Снаружи подъемного моста (все на правой стороне дороги) – Интернет.

При этих трех предположениях мы можем построить легко запоминаемую аллегорию/схему того, как пакетный трафик проходит между самой LAN и WAN (также известной как Интернет или другая подключенная LAN).

С точки зрения устройства, и используя подъемный мост как маршрутизатор:

1. Рыцарь по имени NAT стоит, охраняя подъемный мост.
2. Крестьянин по имени iPad подходит к NAT и говорит, что ему нужно пойти в соседнюю деревню, названную Google, и посмотреть, как готовить шоколад в их библиотеке.
3. Рыцарь NAT кричит сквозь дверь другому рыцарю по имени Dynamo – он действительно знаменит и имеет 2 фамилии, его инициалы DNS. Он говорит NAT, где находится деревня Google по дороге.
4. NAT вынимает из своей брони открытку, записывает на нее адрес деревни Google и местоположение iPad внутри замка, кладет ее в свой карман и дает iPad новую открытку.
5. Что он не говорит iPad, так это то, что на новой открытке у него очень особый адрес, который он получил от короля, и он поменял его на адрес iPad королевским специальным адресом, а затем добавил оригинальный адрес для деревни Google. Затем он дает iPad измененную открытку и говорит ему обменять карты, когда вернется.
6. iPad теперь свободен, чтобы поехать в деревню Google, чтобы найти их рецепт шоколада.

Обратное путешествие, с точки зрения устройства:

1. По возвращении из деревни Google, iPad встречает NAT у подъемного моста, который забирает его карту назад.
2. NAT теперь делает наоборот, стирает адрес короля и заменяет его на адрес iPad внутри замка, отдавая ему его старую открытку.

Трафик внутри замка, с точки зрения устройства:

1. iPad решает, что ему нужен рецепт хлеба, но он видел, как его сосед по имени PC несет хлеб в своей тележке.
2. iPad идет к NAT и говорит, что ему снова нужно пойти в деревню Google за хлебом.
3. NAT говорит, что он может сделать это проще и пишет адрес ПК на открытке iPad, говоря ему, что он не может пойти в деревню Google.

Вышеупомянутая ситуация (Трафик внутри замка) – это то, что происходит в вопросе автора. Запрос NAT никогда не создается, потому что оба IP в его правилах находятся в одной подсети. По аллегории, оба IP-адреса находятся внутри замка.