Re: [tproxy] tproxy in newer 2.6 kernels
Hi Lennert,
We do it in POSTROUTING and that seems to work fine?
Indeed. I just tried and it looks like I could replace tproxy by a simple SNAT and finally upgrade to a newer kernel. Of course, it's not giving the real IP address, but at least some address that remains the same over time. Jan Engelhardt --
On Sun, Jul 23, 2006 at 03:30:04PM +0200, Jan Engelhardt wrote:
Hi Lennert,
Hello,
We do it in POSTROUTING and that seems to work fine?
Indeed. I just tried and it looks like I could replace tproxy by a simple SNAT and finally upgrade to a newer kernel.
That was our main motivation -- we had to move to a newer kernel.
Of course, it's not giving the real IP address, but at least some address that remains the same over time.
Sorry, what do you mean by this? cheers, Lennert
Of course, it's not giving the real IP address, but at least some address that remains the same over time.
Sorry, what do you mean by this?
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.1 0.0.0.0 255.255.255.0 U 0 0 0 eth2 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1 iptables -t nat -A POSTROUTING -i eth2 -o eth1 \ -j NETMAP --to-dest 192.168.1.0/24 iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -m owner \ --uid-owner squid -j SNAT --to-source 192.168.1.2-192.168.1.254 The latter... it does not SNAT to the "real" address (i.e. 192.168.2.123 might get 192.168.1.240 instead of 192.168.1.123), but it suffices. Jan Engelhardt --
On Sun, Jul 23, 2006 at 05:53:13PM +0200, Jan Engelhardt wrote:
Of course, it's not giving the real IP address, but at least some address that remains the same over time.
Sorry, what do you mean by this?
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.1 0.0.0.0 255.255.255.0 U 0 0 0 eth2 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
iptables -t nat -A POSTROUTING -i eth2 -o eth1 \ -j NETMAP --to-dest 192.168.1.0/24 iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -m owner \ --uid-owner squid -j SNAT --to-source 192.168.1.2-192.168.1.254
The latter... it does not SNAT to the "real" address (i.e. 192.168.2.123 might get 192.168.1.240 instead of 192.168.1.123), but it suffices.
Ah, hm, right. Note that the code I posted inserts an SNAT rule every single time a connection is made, so it does let you keep your original source address. (But it needs some app hacking.) cheers, Lennert
On Mon, 2006-07-24 at 00:58 +0200, Lennert Buytenhek wrote:
On Sun, Jul 23, 2006 at 05:53:13PM +0200, Jan Engelhardt wrote:
Of course, it's not giving the real IP address, but at least some address that remains the same over time.
Sorry, what do you mean by this?
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.1 0.0.0.0 255.255.255.0 U 0 0 0 eth2 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
iptables -t nat -A POSTROUTING -i eth2 -o eth1 \ -j NETMAP --to-dest 192.168.1.0/24 iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -m owner \ --uid-owner squid -j SNAT --to-source 192.168.1.2-192.168.1.254
The latter... it does not SNAT to the "real" address (i.e. 192.168.2.123 might get 192.168.1.240 instead of 192.168.1.123), but it suffices.
Ah, hm, right. Note that the code I posted inserts an SNAT rule every single time a connection is made, so it does let you keep your original source address. (But it needs some app hacking.)
And AFAIK iptables has trouble updating large tables, so it only works for a limited number of rules. And packet processing probably stalls while the table is being updated. -- Bazsi
On Tue, Jul 25, 2006 at 09:01:31PM +0200, Balazs Scheidler wrote:
Of course, it's not giving the real IP address, but at least some address that remains the same over time.
Sorry, what do you mean by this?
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.2.1 0.0.0.0 255.255.255.0 U 0 0 0 eth2 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
iptables -t nat -A POSTROUTING -i eth2 -o eth1 \ -j NETMAP --to-dest 192.168.1.0/24 iptables -t nat -A POSTROUTING -s 192.168.1.2 -o eth1 -m owner \ --uid-owner squid -j SNAT --to-source 192.168.1.2-192.168.1.254
The latter... it does not SNAT to the "real" address (i.e. 192.168.2.123 might get 192.168.1.240 instead of 192.168.1.123), but it suffices.
Ah, hm, right. Note that the code I posted inserts an SNAT rule every single time a connection is made, so it does let you keep your original source address. (But it needs some app hacking.)
And AFAIK iptables has trouble updating large tables, so it only works for a limited number of rules. And packet processing probably stalls while the table is being updated.
It only concerns the nat table, which is totally empty otherwise in our case. SNAT rules are kept only until the connection succeeds. cheers, Lennert
Ah, hm, right. Note that the code I posted inserts an SNAT rule every single time a connection is made, so it does let you keep your original source address. (But it needs some app hacking.)
And AFAIK iptables has trouble updating large tables, so it only works for a limited number of rules. And packet processing probably stalls while the table is being updated.
iptables is said to be pretty scalable, even with more than 10000 rules. Ans since someone probably had run iptables to get all the rules in, they must have succeeded. They might have used iptables-restore, which does things slightly different to iptables I believe. Jan Engelhardt --
On Tue, Jul 25, 2006 at 09:44:29PM +0200, Jan Engelhardt wrote:
Ah, hm, right. Note that the code I posted inserts an SNAT rule every single time a connection is made, so it does let you keep your original source address. (But it needs some app hacking.)
And AFAIK iptables has trouble updating large tables, so it only works for a limited number of rules. And packet processing probably stalls while the table is being updated.
iptables is said to be pretty scalable,
That's a bit of a lie :)
even with more than 10000 rules.
There's two separate issues: 1. traversing 10000 rules linearly while doing packet filtering 2. loading a 10000-rule table into the kernel Incremental updates are bad, too -- it is not possible to add or delete a single rule, and you have to copy the _entire_ table to userspace, add/delete your rule, and load the entire table back into the kernel. cheers, Lennert
participants (3)
-
Balazs Scheidler
-
Jan Engelhardt
-
Lennert Buytenhek