On 06/02/2020 15:23, kfm@xxxxxxxxxxxxx wrote:
On 06/02/2020 12:32, ѽ҉ᶬḳ℠ wrote:
On 06/02/2020 07:29, kfm@xxxxxxxxxxxxx wrote:
On 06/02/2020 02:01, ѽ҉ᶬḳ℠ wrote:
The "redirect" statement results in the packet being directed to the
primary address of the interface on which it was received. That's
non-negotiable. As such, "ip daddr" is not supported as an aspect of
its grammar. Indeed, that's not even how it works for the "dnat"
statement.
For instance, these are valid:
redirect
redirect to :8080
This is invalid:
redirect to 1.2.3.4:8080
Suppose that can/should be inferred from the WIKI
"Is a special case of DNAT where the destination is the current
machine."
However, these are valid:
dnat to 1.2.3.4
dnat to 1.2.3.4:8080
Once you address this, any remaining errors should begin to make
more sense.
Right, no error being printed with:
table ip nat { # handle 7
chain input { # handle 1
type nat hook input priority 100; policy accept;
}
chain output { # handle 2
type nat hook output priority -100; policy accept;
}
chain prerouting { # handle 3
type nat hook prerouting priority -100; policy accept;
iif "br-lan" udp dport 53 dnat to 192.168.112.12 #
handle 5
iif "br-lan" tcp dport 53 dnat to 192.168.112.12 #
handle 6
}
chain postrouting { # handle 4
type nat hook postrouting priority 100; policy accept;
oif "pppoe-wan" masquerade # handle 7
}
}
Yet when packet dumping on the downstream client the capture shows no
sign of the rule taking effect but instead the client communicating
(egress and ingress) unabated with the DNS server set by the client.
Since this being pre-routing tracing/logging seems not applicable in
order to figure out what is (not) happening.
It is applicable. The use of dnat (or redirect) amounts to a mostly
transparent form of interception at Layer 4. The client's resolver
will send packets to whichever nameserver it is configured to use.
These packets should be duly intercepted and redirected by the rules
you've shown. Responses will appear to the client as originating from
said nameserver, owing to the effect of dnat along the inverse path.
That is the weird part, I would have expected those showing the ip of
the LAN resolver instance and not the WAN one specified on the client
I'd suggest taking a closer look at what's happening at the
intercepting host with the likes of counter, log, nftrace set 1,
tcpdump etc. You could also use the conntrack userspace tool to
observe and monitor the relevant state entries in your connection
tracking table.
Instead of dumping packets on each traversing interface I made sort of a
litmus test - should have thought of it from the start - and stopped the
LAN resolver instance and DNS stopped for the client as well, despite
having specified a WAN resolver.
Thanks for the input/feedback.
N.B. in the spirit of the topic - daddr works as well (as expected) -
the rule now reading:
table ip nat { # handle 35
chain input { # handle 1
type nat hook input priority 100; policy accept;
}
chain output { # handle 2
type nat hook output priority -100; policy accept;
}
chain prerouting { # handle 3
type nat hook prerouting priority -100; policy accept;
iif "br-lan" ip daddr != 192.168.112.12 udp dport 53
dnat to 192.168.112.12 # handle 5
iif "br-lan" ip daddr != 192.168.112.12 tcp dport 53
dnat to 192.168.112.12 # handle 6
}
chain postrouting { # handle 4
type nat hook postrouting priority 100; policy accept;
oif "pppoe-wan" masquerade # handle 7
}
}
