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.
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.
--
Kerin Millar
