Re: Possible to check if ip daddr belongs to an interface in the prerouting chain?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 29 Apr 2023 13:44:18 +0800
Glen Huang <heyhgl@xxxxxxxxx> wrote:

> > Basically, what it does is lookup at "local" routing table
> 
> I checked my “local” routing table, and my wan IP was there. But somehow, given the following rule, packets with wan IP as the destination still got tproxied:
> 
> chain foo {
>   type filter hook prerouting priority mangle; policy accept;
>   fib daddr . iif type { local, broadcast, multicast } return
>   meta nfproto ipv4 meta l4proto { tcp, udp } tproxy ip to 127.0.0.1:123 meta mark set 1
> }
> 
> I also tried "type == { … }", didn’t help.
> 
> The official wiki mentioned:
> # only accept packets to addresses configured in the *same* interface, eg
> nft add rule x prerouting fib daddr . iif type local accept
> 
> and the man gave this example:
> # drop packets to address not configured on *incoming* interface
> filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
> 
> Which seems to suggest “local” only matches packets whose destination interface must be the same one they originate from? In the lan -> wan case, that’s not the case so I guess it doesn’t match?

Any unicast address for which the destination would be the host itself is considered to be "local". For instance, the following sample ip(8) output informs us that 192.168.1.1 is a local address.

$ ip route get 192.168.1.1
local 192.168.1.1 dev lo src 192.168.1.1 uid 1000
    cache <local>

Rather, it is the concatenation of "daddr" and "iif" that renders that particular fib check so strict. Consider the difference between the following two rules.

fib daddr type != local drop comment "weak host model"
fib daddr . iif type != local drop comment "strong host model"

Let's assume that those rules are to be interpreted within the scope of an input hook. The first rule would reject packets other than those destined to local addresses, irrespective of the interfaces to which the addresses are assigned. The second rule would be stricter still, as it would reject packets other than those destined to local addresses that are also assigned to the interface at which any given packet arrives.

-- 
Kerin Millar



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux