Jan Engelhardt a écrit :
On Sunday 2008-03-30 18:10, Pascal Hambourg wrote:
I agree that the use of the nat table for any purpose not related
to NAT should be avoided. However the advantage of the nat table is
that it sees only one packet per connection, while "-m conntrack
--ctstate NEW" or "-m state --state NEW" may match multiple packets
per connection, e.g. duplicate TCP SYN or all UDP sent packets in
the original direction before the first packet sent in the return
direction.
That's nonsense -- the nat table sees every packet that is IPCT_NEW:
The nonsense would be that the nat table sees packets which don't create
a new connection, because this would be totally useless.
iptables -t nat -A OUTPUT -d 134.76.13.21 -p tcp --syn -j LOG
--log-prefix "[nat] "
iptables -t filter -A OUTPUT -d 134.76.13.21 -p tcp --syn -j LOG
--log-prefix "[filt] "
iptables -t filter -A OUTPUT -d 134.76.13.21 -p tcp --syn -j DROP
This test is bogus because the final DROP deletes the conntrack entry
(the packet is dropped before the connection is confirmed) so each
packet appears to create a new connection and goes through the nat table.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
