По какому пути пройдут пакеты в nftables?

Question

[Александр]

Помогите пожалуйста разобраться с порядком прохождения пакетом таблиц и цепочек в nftables
Вроде в iptables все было проще, а тут с таблицами, цепочками, хуками и прыжками не могу понять, а в интернете такой информации почти нет.

К примеру сеть:
маршрутизатор на openwrt22 с nftables - 10.0.0.1, 10.33.33.1
клиент1 - 10.0.0.22 - подключен в br-lan
клиент2 - 10.0.0.44 - подключен в br-lan

Какие цепочки и правила пройдет пакет от клиента1 к клиенту2 на 22 TCP порт?
Верно ли что никакие, портому что семейство bridge не настроено?

Какие цепочки и правила пройдет первый пакет от клиента1 к маршрутизатору на 22 TCP порт? правильно ли так?
......................................bridge / not set accept
prerouting........-300........inet fw4 raw_prerouting default accept
prerouting........-150........inet fw4 mangle_prerouting / default accept
prerouting........-100........inet fw4 dstnat / jump dstnat_lan / back to dstnat / default accept
prerouting........0.............inet nft-qos-monitor download / default accept
prerouting........0.............inet fw4 prerouting / jump helper_lan / back to prerouting / default accept
input................-400........inet banIP wan-input / index 2 accept
input................-150........inet fw4 mangle_input / default accept
input................0.............inet fw4 input / jump input_lan / jump accept_from_lan / index 1 accept

Какие таблицы и хуки пройдет пакет от клиента1 к маршрутизатору на внешний адрес(10.33.33.1) ?
Всё будет как и в прошлом вопросе так как ничего не изменилось?

В каких случая пакет попадает в пространство указанное на схеме как "ARP layer" ? или это просто обработка в семействе таблиц arp и она идет парралельно с другими?
На схеме input bridge, forward bridge, ... это тоже хуки только в семействе bridge?
Все ли базовые цепочки с подходящим хуком пройдет пакет или как только найдет подходящее правило покинет хук/цепочку/все цепочки с учетом jump?
Порядок прохождения таблиц будет по порядку их перечисления в конфиге или пакет будет прыгать по приоритетам цепочек?

Схема работы nftables и мой конфиг под спойлером.

КОНФИГ и СХЕМА

table inet fw4 {
        chain input {
                type filter hook input priority 0; policy accept;
                iifname "lo" accept 
                ct state established,related accept 
                tcp flags syn / fin,syn,rst,ack jump syn_flood 
                iifname "br-lan" jump input_lan 
                iifname "eth1" jump input_wan 
        }

        chain forward {
                type filter hook forward priority 0; policy drop;
                ct state established,related accept 
                iifname "br-lan" jump forward_lan 
                iifname "eth1" jump forward_wan 
        }

        chain output {
                type filter hook output priority 0; policy accept;
                oifname "lo" accept 
                ct state established,related accept 
                oifname "br-lan" jump output_lan 
                oifname "eth1" jump output_wan 
        }

        chain prerouting {
                type filter hook prerouting priority 0; policy accept;
                iifname "br-lan" jump helper_lan 
        }

        chain handle_reject {
                meta l4proto tcp reject with tcp reset 
                reject 
        }

        chain syn_flood {
                limit rate 25/second burst 50 packets return 
                drop 
        }

        chain input_lan {
                ct status dnat accept 
                jump accept_from_lan
        }

        chain output_lan {
                jump accept_to_lan
        }

        chain forward_lan {
                tcp dport 853  jump reject_from_lan 
                udp dport 853  jump reject_from_lan 
                jump accept_to_wan 
                ct status dnat accept 
                jump accept_to_lan
                log prefix "drop lan forward: "
        }

        chain helper_lan {
        }

        chain accept_from_lan {
                iifname "br-lan"  accept 
        }

        chain accept_to_lan {
                oifname "br-lan"  accept 
        }

        chain input_wan {
                meta nfproto ipv4 udp dport 68  accept 
                jump drop_from_wan
        }

        chain output_wan {
                jump accept_to_wan
        }

        chain forward_wan {
                jump drop_to_wan
        }

        chain accept_to_wan {
                oifname "eth1"  accept 
        }

        chain drop_from_wan {
                iifname "eth1"  drop 
        }

        chain drop_to_wan {
                oifname "eth1"  drop 
        }

        chain dstnat {
                type nat hook prerouting priority -100; policy accept;
                iifname "br-lan" jump dstnat_lan 
        }

        chain srcnat {
                type nat hook postrouting priority 100; policy accept;
                oifname "eth1" jump srcnat_wan 
        }

        chain srcnat_wan {
                meta nfproto ipv4 masquerade 
        }

        chain raw_prerouting {
                type filter hook prerouting priority -300; policy accept;
        }

        chain raw_output {
                type filter hook output priority -300; policy accept;
        }

        chain mangle_prerouting {
                type filter hook prerouting priority -150; policy accept;
        }

        chain mangle_postrouting {
                type filter hook postrouting priority -150; policy accept;
        }

        chain mangle_input {
                type filter hook input priority -150; policy accept;
        }

        chain mangle_output {
                type route hook output priority -150; policy accept;
        }

        chain mangle_forward {
                type filter hook forward priority -150; policy accept;
                iifname "eth1" tcp flags syn tcp option maxseg size set rt mtu 
                oifname "eth1" tcp flags syn tcp option maxseg size set rt mtu 
        }

        chain reject_from_lan {
                iifname "br-lan"  log prefix "reject lan in: " jump handle_reject 
        }

        chain dstnat_lan {
                tcp dport 53  redirect to :53 
                udp dport 53  redirect to :53 
        }
}

table inet banIP {
        set allowlistv4MAC {
                type ether_addr . ipv4_addr
                policy memory
                flags interval
                auto-merge
        }

        set allowlistv4 {
                type ipv4_addr
                policy memory
                flags interval
                auto-merge
        }

        set blocklistv4 {
                type ipv4_addr
                policy memory
                flags interval,timeout
                auto-merge
        }

        chain wan-input {
                type filter hook input priority -400; policy accept;
                ct state established,related  accept
                iifname != "eth1"  accept
                meta nfproto ipv4 udp sport 67-68 udp dport 67-68  accept
                icmp type echo-request limit rate 1000/second  accept
                ip saddr @allowlistv4  accept
                ip saddr @blocklistv4 log prefix "blocklistv4: " level notice  drop
        }

        chain wan-forward {
                type filter hook forward priority -400; policy accept;
                ct state established,related  accept
                iifname != "eth1"  accept
                ip saddr @allowlistv4  accept
                ip saddr @blocklistv4 log prefix "blocklistv4: " level notice  drop 
        }

        chain lan-forward {
                type filter hook forward priority -400; policy accept;
                ct state established,related  accept
                oifname != "eth1"  accept
                ether saddr . ip saddr @allowlistv4MAC  accept
                ip daddr @allowlistv4  accept
       }
}
table inet nft-qos-monitor {
        chain upload {
                type filter hook postrouting priority 0; policy accept;
                ip saddr 10.0.0.22 counter packets 2523808 bytes 5721457585
                
        }

        chain download {
                type filter hook prerouting priority 0; policy accept;
                ip daddr 10.0.0.22 counter packets 1961733 bytes 161657555
                
        }
}

Answer 1

[Дмитрий]

При общении клиент1 - клиент2 роутер не участвует, т.к. клиенты находятся в одной сети и будут общаться напрямую друг с другом.
Клиент1-Роутер - порядок верный, сначала Prerouting, потом input в обоих случаях
ARP layer - судя по схеме обрабатывается когда приходит пакет не из бриджа и это ARP-запрос.
Пакет будет проходить все цепочки до тех пор, пока не обработается каким-либо терминирующим правилом - аксепт или дроп.
Пакет попадает в ту или иную цепочку в зависимости от адреса назначения и входного интерфейса роутера

Comments

[Александр]

Огромное спасибо, теперь уверен, что двигаюсь правильно.
Для удобства расставлю себе цепочки по порядку обработки.

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

Видимо из-за того, что интерфейс br-lan мостовой, nftables все таки обрабатывает эти пакеты хоть они и в одном широковещательном домене.

10.99.99.3 - комп по ethernet
10.99.99.4 - андроид по wifi
9 пингов все поймал

admin@OpenWrt ~# nft list table bridge my1
table bridge my1 {
        chain pr {
                type filter hook forward priority filter; policy accept;
                ip saddr 10.99.99.4 ip daddr 10.99.99.3 counter packets 9 bytes 756
        }
}

[Дмитрий]

Так как разная среда передачи (провод и вайфай) трафик должен перейти из одной в другую, а это делает в вашем случае именно роутер. Если коммутатора после роутера нет, то на бридже будут ловиться пакеты.