On Fri, 2008-07-04 at 12:53 +0200, thomas.wenz@gmx-topmail.de wrote:
Hi,
Perhaps it was just too late for me ;) The python-kzorp package was there but I didn't notice it and dpkg didn't complain about it (it's not a dependancy of zorp). Sorry!
As you predicted I get some startup errors complaining that it can't flush KZorp config. If I understand correct, KZorp is a faster solution and allows including iptables/NAT rules into Zorp. Are there any other advantages I missed?
Not really. Some of the access control is pushed down into kernel space, so that you can use the same access control model for forwarded traffic as for proxied traffic. Also, you can use zones inside your packet filter rules.
However, It's not yet working because it somehow gets wrong IPs with my unchanged config form the old Zorp(dest is wrong, remote and local are correct): core.debug(6): (dsp/dispatch:0): Incoming connection; protocol='1', remote='AF_INET(10.1.1.1:1704)', local='AF_INET(10.1.1.251:50080)', dest='AF_INET(10.1.1.251:50080)' It then fetches the GET request and tries to connect to itself (which fails).
That's bad, Zorp could not find out the original target address. Where did you get your kernel from? I mean which tproxy version are you using? The one destined for kernel inclusion is dubbed version 4.1, but it is completely incompatible with what we currently have in our ZorpOS kernel, which is dubbed version 4.0.
However, I did not notice the self.request_stack["GET"] entry being performed. Is this done after the connection has been established? If so, I think this would be a little bit late...in my opinion it should be before header filtering or earlier in order to be able to adjust the content length header (can't be adjusted through the stacked program as far as I read), log the umodified request and to prevent connecting in case there's something evil in the data part.
The "GET" request has no data payload, that's why it is not stacking anything. For POST it should start the stacked program before connecting to the destination.
Do I perhaps need a new kernel with the new TProxy 4.0 as there's a line core.debug(6): (nosession): System dependant init; sysdep_tproxy='tproxy40' If so, should a leave KZorp out of the kernel because if I compile it in, I need to configure it, correct?
From Zorp's point of view it does not matter whether you use tproxy 4.0 or tproxy 4.1, it should work with both.
How do you redirect traffic to Zorp? Are you using TPROXY target or REDIRECT (in the nat table?) If the latter then I understand why it does not detect the original target address. -- Bazsi