>> 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 > 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? -g -- 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
