> > An alternative implementation would apply address mangling to each > > individual skb exactly once. For both directions, the conntracking > > structure would contain the set of changes to apply to IP and protocol > > addresses, and possibly there would be a _precomputed_ checksum adjust > > stored within the conntrack. > > That breaks a lot of things, mainly that your ruleset is nolonger able > to match on the best combination of source and destination address.
I am aware that this would break things. As I'm not using NAT myself in the real world (except for REDIRECT), I want to hear real world uses of that distinction, so I can think about what's really needed. > > Now, the "step-by-step" application in the current framework, > > if I understand things correctly, is visible in the iptables > > rule chains in the various tables. What I wonder about is, > > how many rulesets _rely_ on such "partial modifications" of > > the individual skb, and what is the purpose of that usage? > > It's absolutely necessarry. Where would this 'single' point in the stack > be? at post_routing is too late, because the routing decision is already > made. So you would need to do all nat at pre_routing. Yes, that's the basic idea. > this means that you do SNAT at prerouting. So your firewall ruleset will never > see the real (e.g. 192.168.x.x) address of SNATed / MASQUERADEd connections. The prerouting operation _could_ be split into a PRE-MANGLE and POST-MANGLE part, with the NAT operation seen as yet another mangling. > Another issue: how big is the optimization? How many connections do > really have SNAT and DNAT at the same time? In most cases you only > have one manipulation. That's the main reason for me thinking about the thing. We currently have 6 manip[] structures in each conntrack, and use 0 of them most of the time (for non-NATted connections), and 1 of them almost all of the rest of the time. For combined SNAT/DNAT we would need 2. We have 6, one for each of 3 different hooks. It's the latter I call into question here. > Precomputed checksum mangling? mmh... could be interesting - but this > could be implemented with the current code as well. Sure, store the checksum delta along with the manips. Makes the 6 of them still a bit larger, but if would help... However, I doubt that it would help that much. The current per-packet incremental checksum computation does not dominate the conntrack operation. best regards Patrick
