Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> -------------------------------------
> +Note that the tproxy statement is non-terminal to allow post-processing of
> +packets, such logging the packet for debugging.
> +
> +.Example ruleset for tproxy statement with logging
> +-------------------------------------
> +table t {
> + chain c {
> + type filter hook prerouting priority mangle; policy accept;
> + udp dport 9999 tproxy to :1234 log prefix "packet tproxied: " accept
> + log prefix "no socket on port 1234 or not transparent?: " drop
> + }
I'd suggest to use anon chain here:
udp dport 9999 goto {
tproxy to :1234 log prefix "packet tproxied: " accept
log prefix "no socket on port 1234 or not transparent?: " drop
}
I also think it might make sense to merge/add bits from the kernel
documentation file.
(Documentation/networking/tproxy.rst).
None of these examples will work in case the destination IP is
going to be forwarded, the example only works for port "redirect".
Maybe:
+As packet headers are unchanged, packets might be forwarded instead of delivered
+locally. This can be avoided by adding policy routing rules and the packet mark.
+
+.Example policy routing rules for local redirection:
+----------------------------------------------------
+ip rule add fwmark 1 lookup 100
+ip route add local 0.0.0.0/0 dev lo table 100
+----------------------------------------------------
+
+Then, add "mark set 1" right after the "tproxy statement".
I'm not sure how verbose it should be, tproxy is complicated
due to how its interacting with routing engine, even application
needs to do special things (IP_TRANSPARENT sockopt). Maybe
examples should also include "meta mark set 1" bit?
> +This is a change in behavior compared to the legacy iptables TPROXY target
> +which is terminal. To terminate the packet processing after the tproxy
> +statement, remember to issue a verdict as in the example above.
Agree, it makes sense to add this.
