On 13/02/2020 11:59, kfm@xxxxxxxxxxxxx wrote:
On 13/02/2020 11:41, ѽ҉ᶬḳ℠ wrote:
<snip>
The current kernel deployed, which kconf is beyond my control, is
missing the flag to support sets and thus vmap. But that aside
something like this seems to work
table inet filter {
chain input { type filter hook input priority 0;
policy drop; iifname pppoe-wan jump wan_i; }
chain wan_i { ip saddr 0.0.0.0/32 udp sport 67 ip
daddr 255.255.255.255/32 udp dport 68 accept; }
}
Indeed, vmap is by no means required. This is equivalent to the
previously suggested input chain, only marginally less efficient:
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
ct state invalid,untracked drop
iifname "lo" accept
iifname "pppoe-wan" goto wan_i
iifname "eth0-lan" goto lan_i
}
Note that goto is an optimisation. It would still be appropriate to
use jump in the case that you need for the packet to be able to fall
through one of the user-defined chains and return to the input chain
in order to be subjected to other rules there. In this particular
example, it is not possible for iifname to match "eth0-lan" if it did
not already match "pppoe-wan" and, because there are no further rules
in the input chain, the use of goto is fine.
Thanks for the hint/tip (and other input) - goto makes sense in this
case, saves CPU cycles (even if just a tiny bit - but why waste it anyway).
