On Wed, 11 Mar 2015 17:27:35 -0400 Glen Miner <shaggie76@xxxxxxxxxxx> wrote: > >> What it does: makes UDP NAT proxies so people with strict-NAT or > > multi-layer NAT can communicate. This essentially works out to be 4 > > iptables rules created for a pair of peers. They talk to our server and > > our server makes it look like they're talking to each other; fighting > > bad NAT with our NAT is somewhat ironic but it's quite elegant. > > > > What exactly are these four rules, and what do they accomplish? > > aAddr : aPort is player A's real ip : port > bAddr : bPort is player B's real ip : port > nAddr : anPort is what player B uses to talk to A > nAddr : bnPort is what player A uses to talk to B > > echo "*nat > :PREROUTING - [0:0] > -I PREROUTING -p udp -s $aAddr --sport $aPort -d $nAddr --dport $bnPort -j DNAT --to $bAddr:$bPort > -I PREROUTING -p udp -s $bAddr --sport $bPort -d $nAddr --dport $anPort -j DNAT --to $aAddr:$aPort > :POSTROUTING - [0:0] > -A POSTROUTING -p udp -s $aAddr --sport $aPort -d $bAddr --dport $bPort -j SNAT --to $nAddr:$anPort > -A POSTROUTING -p udp -s $bAddr --sport $bPort -d $aAddr --dport $aPort -j SNAT --to $nAddr:$bnPort > COMMIT > " | iptables-restore --noflush It looks like you will have a very long list of rules in PREROUTING and POSTROUTING. You will likely have a scalability issues due to this, as iptables will process these rules linear. Thus, as you add more rules, the overhead per packet increase. You are basically shooting yourself in the foot, by building your ruleset like this. I solved the iptables update speed back in 2007-2008, and also had a method for building a subnet-skeleton search tree with iptables chains, what reduced the lookup complexity from O(n) to O(log N). See my user-presentation: http://people.netfilter.org/hawk/presentations/nfws2008/nfws2008_userday_iptables_scale.pdf See my developer presentation: http://people.netfilter.org/hawk/presentations/nfws2008/nfws2008_developers_iptables_scale.pdf The iptables update speed, I on-purpose "only" fixed for chain-lookups. I left-in the scalability problem of updating a very long list-of-rules in a single chain, because if someone would do that (like you) they should experience this slowdown, and hopefully stop to think about weather they are doing some thing wrong, like you ;-). (As you are only inserting or adding rules, not adding or deleting rules in the middle of the chain, you are not hitting the really bad parts). > > You won't be happy changing iptables rules on the fly for each > > customer. Hire somebody who can program in C, point them at the > > iptables kernel NAT module implementation, and maybe ipset, and get > > them hacking away at a solution that works without table manipulation. > > I can program in C; like I said: I translated the above command + > some conntrack junk to direct function calls to skip process creation > and parsing logic for 20x better performance. However, it's not > really clear where I'd go instead short of reinventing iptables / > conntrack and lord knows what else. Are you suggesting I write my own > kernel hooks? With my experience today, I would probably have written a simple netfilter/iptables module that would do the work, having a hash-table to match my rules, and be externally configurable via netlink messages (to add and remove customers). (Which is basically what Jan said about hiring somebody with experience). Today, we have nftables. I'm not very experienced with nftables, but I think that you problem might be solvable by using nftables "set" functionality. Reducing your entire ruleset to 4 nftables "set" rules. A third option, is using conntrack-tools [1], like Jan also mentioned. [1] http://netfilter.org/projects/conntrack-tools/index.html -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
