Petr Pisar a écrit :
and after doing this excercise I can't see any change on counters in
POSTROUTING chain. Naturaly I can't see anything in the kernel log (as
you can see, I log everything before MASQ and after that).
I seems, these magic packets are completly bypassing POSTROUTING chain.
I found out too that TCP traffic goes inside this chain only with first
SYN packet. After that there the packets are I don't see them anymore.
Is it normal?
So, I have one workaround. These magic packets are INVALID from point of
state module's view.
Connection tracking state is the key to explain all that you observed.
Only NEW packets can create an entry in the connection tracking table
(which contents can been seen through /proc/net/ip_conntrack) and can go
through the 'nat' chains. That's why :
- INVALID packets bypass the nat chains, thus aren't NATed nor counted
- only the first NEW packet of a connection, which is usually a SYN in
TCP connections, goes through the nat chains. Duplicate SYN, although
NEW too, or subsequent packets belonging (ESTABLISHED) or related
(RELATED) to the same connection in either direction don't. However all
get automatically NATed according to the conntrack entry in a way
determined by how the first packet was NATed.
I'm not sure if any INVALID packet can also be considered as a health
packet. Can you see any false positivities?
Unlike malformed packets which the experimental "unclean" match tries to
detect, INVALID packets are not "unhealthy" in nature, they're just
unexpected. And yes, false positive can occur. With kernels older than
2.4.29, some locally-generated ICMP replies are wrongly considered
INVALID instead of RELATED.
