Re: TPROXY support in Squid 3
Take 2: includes initial modularisation (untested; I'll test it at home this weekend when I get my tproxy box back online) and configure magic (with placeholders for tproxy4/freebsd.) http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff TODO: * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY from the source * look at modifying comm_open*() to take a setup flag, and pass this in where required * make sure upstream/peer-forwarded requests aren't thrown to the tproxy code. * Once thats committed and working, go through and rename everything to be slightly more sensible. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries: Currently: fde::flags::transparent == 'intercept/non-intercept' fde::flags::tproxy == real-transparent/non-transparent (new) COMM_TRANSPARENT == real-transparent Their use is currently good for what they do. A small re-naming is all that is needed there. I'm thinking flags::intercept and flags::realtransparent. In the request flags I would use intercepted and spoofclientip, with intercepted replacing the current transparent flag. Probably the same in the fde, where tproxy sets both. fde: intercepted This connection was intercepted spoofclientip Please mark received requests for spoofing the client ip request intercepted This requequest was received on an intercepted conection, need to act as if we were the origin server.. spoofclientip Spoof the outgoing connection using the client ip It's possible one may want to use spoofing without interception, and the above opens up for the possibility of marking requests with spoofclientip even without having to be received on an intercepted connection. Regards Henrik
Re: TPROXY support in Squid 3
tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd: Take 2: includes initial modularisation (untested; I'll test it at home this weekend when I get my tproxy box back online) and configure magic (with placeholders for tproxy4/freebsd.) http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff Comments: commTransparentRemote needs to move into comm_openex. You can't fit tproxy4/freebsd in a reasnoable manner otherwise. By removing the need_linux_tproxy you just killed the capability to fall back no non-tproxy connections if we failed to gain the capabilities needed.. cache.log will now get filled with tons of errors in such setups., where you earlier only got a single warning about continuing without tproxy support.. * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY from the source TPROXY both versions need the special capabilities, and we do not want to keep these capabilities if TPROXY is not used.. * make sure upstream/peer-forwarded requests aren't thrown to the tproxy code. Consider a local proxy connecting to a remote proxy. You may want to still show the actual client IPs to the remote proxy just as you do to websites.. A cache_peer flag controlling this would make sense, probably defaulting to not spoof the client ip on requests sent to peers.. Regards Henrik
Re: TPROXY support in Squid 3
On Tue, Apr 08, 2008, Henrik Nordstrom wrote: tis 2008-04-08 klockan 14:28 +0800 skrev Adrian Chadd: Take 2: includes initial modularisation (untested; I'll test it at home this weekend when I get my tproxy box back online) and configure magic (with placeholders for tproxy4/freebsd.) http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff Comments: commTransparentRemote needs to move into comm_openex. You can't fit tproxy4/freebsd in a reasnoable manner otherwise. Yup, that'd be part of the follow up work. This first cut is to break out what is there; the next commit would be further API tidyups to support TPROXY4 and FreeBSD. By removing the need_linux_tproxy you just killed the capability to fall back no non-tproxy connections if we failed to gain the capabilities needed.. cache.log will now get filled with tons of errors in such setups., where you earlier only got a single warning about continuing without tproxy support.. Yes, I have to give that a little more thought. I may keep the global but not call it linux_tproxy.. * pull out the capabilities stuff, removing the last #ifdef LINUX_TPROXY from the source TPROXY both versions need the special capabilities, and we do not want to keep these capabilities if TPROXY is not used.. Ok. * make sure upstream/peer-forwarded requests aren't thrown to the tproxy code. Consider a local proxy connecting to a remote proxy. You may want to still show the actual client IPs to the remote proxy just as you do to websites.. A cache_peer flag controlling this would make sense, probably defaulting to not spoof the client ip on requests sent to peers.. I read the current code as don't do that; its the behaviour I'd like to maintain. We can always add the functionality later. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote: tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries: Currently: fde::flags::transparent == 'intercept/non-intercept' fde::flags::tproxy == real-transparent/non-transparent (new) COMM_TRANSPARENT == real-transparent Their use is currently good for what they do. A small re-naming is all that is needed there. I'm thinking flags::intercept and flags::realtransparent. In the request flags I would use intercepted and spoofclientip, with intercepted replacing the current transparent flag. Probably the same in the fde, where tproxy sets both. fde: intercepted This connection was intercepted spoofclientip Please mark received requests for spoofing the client ip request intercepted This requequest was received on an intercepted conection, need to act as if we were the origin server.. spoofclientip Spoof the outgoing connection using the client ip Please use camelCase or underscore_separators to make new names more readable. Thank you, Alex.
Re: TPROXY support in Squid 3
tis 2008-04-08 klockan 22:17 +0800 skrev Adrian Chadd: * make sure upstream/peer-forwarded requests aren't thrown to the tproxy code. I read the current code as don't do that; its the behaviour I'd like to maintain. We can always add the functionality later. Yes, it is not something you want to have done by default as in many cases peerings is local.. Regards Henrik
Re: TPROXY support in Squid 3
On Tue, Apr 08, 2008, Adrian Chadd wrote: Take 3: http://www.creative.net.au/diffs/20080408-tproxy-fix-2.diff * restored the global flag which indicates tproxyness; renamed to enable_spoof_srv * moved the tproxy bind stuff into comm.c, with a flag to comm_openex() * changed forward.c to try a tproxy comm_openex() if requested, falling back to a non-tproxy comm_openex() if that fails. TODO: * actually call the ipt_*Capabilities() hooks; I'll go add that in now. This stuff has almost no testing! Its more for feedback; I'll try to fire up the tproxy+wccp testbench this weekend to do some actual tproxy2 and tproxy4 testing before I look at committing it. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
On Tue, 2008-04-08 at 15:15 +0200, Henrik Nordstrom wrote: tis 2008-04-08 klockan 17:59 +1200 skrev Amos Jeffries: Currently: fde::flags::transparent == 'intercept/non-intercept' fde::flags::tproxy == real-transparent/non-transparent (new) COMM_TRANSPARENT == real-transparent Their use is currently good for what they do. A small re-naming is all that is needed there. I'm thinking flags::intercept and flags::realtransparent. In the request flags I would use intercepted and spoofclientip, with intercepted replacing the current transparent flag. Probably the same in the fde, where tproxy sets both. fde: intercepted This connection was intercepted spoofclientip Please mark received requests for spoofing the client ip request intercepted This request was received on an intercepted connection, need to act as if we were the origin server.. spoofclientip Spoof the outgoing connection using the client ip Please use camelCase or underscore_separators to make new names more readable. Agreed. For the flags I'm keeping with the lower case and using _. I'm part way through rollout of the 'intercepted' flag change now. Next up will be replacing the tproxy flag. I've enabled both flags as always-present where they are used and dropped the LINUX_NETFILTER and LINUX_TPROXY4 macros back to IPInterception.cc internals. LINUX_TPROXY2 requires a few extra bits of code which are still unique so until its agreed for dropping there are bits where its better to leave it. Amos
Re: TPROXY support in Squid 3
Adrian Chadd wrote: On Mon, Mar 31, 2008, Alex Rousskov wrote: What about Adrian plans (if I understood them correctly) to add TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a good enough reason to continue supporting unsupported TPROXY versions? The FreeBSD API will be almost like the TPROXY-4 API. I'd suggest supporting TPROXY-2 for a few reasons: * Those who are using it may not want to track the latest kernel + TPROXY patches for various reasons (if it just works; company policy; etc.) and I think its easy enough to maintain support for both without too much hassle. * Supporting both TPROXY-2 and TPROXY-4 will (hopefully!) force someone to integrate it cleanishly and avoid the Squid-2 ip interception mess! * Thus making it easier for me to drop in a FreeBSD version of tproxy without too much hassle (or #ifdef's for that matter.) It shouldn't be that difficult to isolate the bits of the code required for spoofing the client IP in the request versus the TPROXY-specific stuff. In fact, the only tproxy-specific stuff I can really see is: * the logic in forward.c to the local bind, which can be wrapped up as part of the socket creation process, and * The initialisation code, which in the tproxy-2 case does capabilities magic. Adrian We have come up with a 'final-beta' patch for squid-3 now. http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch Just waiting on Laszlo final approval. It's pretty much: * adding a COMM_TRANSPARENT flag to comm_openex(...) * adds a comm_set_transparent for internal comm use to do setsockopt() * adding a transparent flag to all fde's - set to 1 on fde's which are opened with the transparent flag OR, accepted from a listening fde with transparent flag. * override getOutgoingAddr ACL checks to produce the transparent client-address as outgoing addr. * adapt the existing Netfilter NAT getsockopt() for tproxy option. Should be easy to drop the squid side of your emulated TPROXY-4 alterations in there Adrian. Amos -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: TPROXY support in Squid 3
mån 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
Some comments...
There should be a general TPROXY define, shared by all, or the common
os-independent code should always be enabled. I do not want to see #if
LINUX_TPROXY2 || LINUX_TPROXY4 defines in the general code. Such ifs
should only be seen in the lowlevel implementation. And from a code
maintenance perspective it's best is the common code is always built,
just as is done for the transparent interception code. The drawback is
that it costs one or two cpu cycles more per requests even if the
feature is not available on the platform but it's much much less likely
the feature gets broken by other changes.
+/* AYJ: do we actually need to set this again on every accept? */
+if(fd_table[fd].flags.transparent == 1) {
+comm_set_transparent(sock);
+F-flags.transparent = 1;
+}
You need to at least set the internal flag. But you most likely do no
need to make the comm call telling the kernel it's a transparent
connection (it already knows..)
Is this indended?
@@ -652,7 +673,6 @@
addr.GetAddrInfo(AI);
AI-ai_socktype = sock_type;
AI-ai_protocol = proto;
-AI-ai_flags = flags;
debugs(50, 3, comm_openex: Attempt open socket for: addr );
Regards
Henrik
Re: TPROXY support in Squid 3
In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree.
There should be a SERVER_SPOOF define which ties in all of the connection
tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket
manipulation.
Gah, this makes me want to just ignore more classwork and fix the tproxy
support in Squid-2 to show how it should be done..
Adrian
On Mon, Apr 07, 2008, Henrik Nordstrom wrote:
m??n 2008-04-07 klockan 23:11 +1200 skrev Amos Jeffries:
We have come up with a 'final-beta' patch for squid-3 now.
http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch
Just waiting on Laszlo final approval.
Some comments...
There should be a general TPROXY define, shared by all, or the common
os-independent code should always be enabled. I do not want to see #if
LINUX_TPROXY2 || LINUX_TPROXY4 defines in the general code. Such ifs
should only be seen in the lowlevel implementation. And from a code
maintenance perspective it's best is the common code is always built,
just as is done for the transparent interception code. The drawback is
that it costs one or two cpu cycles more per requests even if the
feature is not available on the platform but it's much much less likely
the feature gets broken by other changes.
+/* AYJ: do we actually need to set this again on every accept? */
+if(fd_table[fd].flags.transparent == 1) {
+comm_set_transparent(sock);
+F-flags.transparent = 1;
+}
You need to at least set the internal flag. But you most likely do no
need to make the comm call telling the kernel it's a transparent
connection (it already knows..)
Is this indended?
@@ -652,7 +673,6 @@
addr.GetAddrInfo(AI);
AI-ai_socktype = sock_type;
AI-ai_protocol = proto;
-AI-ai_flags = flags;
debugs(50, 3, comm_openex: Attempt open socket for: addr );
Regards
Henrik
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd: In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree. There should be a SERVER_SPOOF define which ties in all of the connection tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket manipulation. I say it shouldn't even be a SERVER_SPOOF define. Make the generic parts always compiled, doing nothing if spoofing capabilities is not available. Regards Henrik
Re: TPROXY support in Squid 3
Henrik Nordstrom wrote: tis 2008-04-08 klockan 01:16 +0800 skrev Adrian Chadd: In fact, there shouldn't be any LINUX_TPROXY* defines in the main codetree. There should be a SERVER_SPOOF define which ties in all of the connection tracking stuff, and a clean cut API for doing TPROXY2/TPROXY4/etc socket manipulation. I say it shouldn't even be a SERVER_SPOOF define. Make the generic parts always compiled, doing nothing if spoofing capabilities is not available. I'm agreeing with Henrik on this one. Transparent mode basics should be always available. But, baby steps people: - Get it in - Get it tested. - Polish into a class. So far we are at #1 Amos -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: TPROXY support in Squid 3
tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries: But, baby steps people: - Get it in - Get it tested. - Polish into a class. So far we are at #1 And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the code, even if it's just adding to the existing #if.. Get the basic polished up as part of #1.. it's simple, makes things much cleaner, and #3 gets a much narrover focus. Regards Henrik
Re: TPROXY support in Squid 3
On Tue, Apr 08, 2008, Henrik Nordstrom wrote: tis 2008-04-08 klockan 09:57 +1200 skrev Amos Jeffries: But, baby steps people: - Get it in - Get it tested. - Polish into a class. So far we are at #1 And I won't approve the change of sprinkling #if LINUX_TPROXY4 over the code, even if it's just adding to the existing #if.. Get the basic polished up as part of #1.. it's simple, makes things much cleaner, and #3 gets a much narrover focus. My attempt for Squid-2, step 1: http://www.creative.net.au/diffs/20080408-tproxy-fix-1.diff This just removes LINUX_TPROXY for the global state stuff and the linux_needs_tproxy global variable. Looking at it, it probably makes more sense to do this: comm_open(with flags if tproxy) if (tproxy for this request) comm_bind(non-local bind) if (comm_bind failed) disable tproxy for this request if (not tproxy) comm_bind(local bind - from the outgoing addr ACL logic) How does that sound? Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
On Mon, Apr 07, 2008, Amos Jeffries wrote: We have come up with a 'final-beta' patch for squid-3 now. http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch Just waiting on Laszlo final approval. It's pretty much: * adding a COMM_TRANSPARENT flag to comm_openex(...) This is the only thing I'm a bit weird on. This means that the same flag to TPROXY is used for outgoing sockets and incoming sockets? I'm thinking about seperating them just to make it absolutely clear - it doesn't matter that the backend sends the same sockopt and calls the same bind(). I don't think it matters in the FreeBSD case either as I'm pretty sure the patch I have here uses the same flag for incoming and outgoing sockets. What do you (and others) think? Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
Adrian Chadd wrote: On Mon, Apr 07, 2008, Amos Jeffries wrote: We have come up with a 'final-beta' patch for squid-3 now. http://treenet.co.nz/projects/squid/patches/tproxy-squid-3_20080407.patch Just waiting on Laszlo final approval. It's pretty much: * adding a COMM_TRANSPARENT flag to comm_openex(...) This is the only thing I'm a bit weird on. This means that the same flag to TPROXY is used for outgoing sockets and incoming sockets? The sockets open either as listening (needs IP_TRANSPARENT option set for the OS to track new inbound connections as TPROXY targets etc.) Or as outbound spoofed connects (needs IP_TRANSPARENT option set for the OS to track the connection for special TPROXY handling.) Both need the sockopt set in the same manner on connect. Sequence matters for one, but not the other. So its done the same way for both and in sequence where it handles both nicely. I'm thinking about seperating them just to make it absolutely clear - it doesn't matter that the backend sends the same sockopt and calls the same bind(). Make what clear? that is a socket involved with transparent handling? Thats all the information that is needed by squid to operate well. It's simpler to keep it in squid as a boolean flag. Tri-states can get messy. Especially in squid case where we already have the non-transparent intercept handling for non-tproxy methods intertwined at higher levels. Keep-it-simple and all that. I don't think it matters in the FreeBSD case either as I'm pretty sure the patch I have here uses the same flag for incoming and outgoing sockets. What do you (and others) think? I think we need to clean up the two flags floating around squid rather than adding more state. Currently: fde::flags::transparent == 'intercept/non-intercept' fde::flags::tproxy == real-transparent/non-transparent (new) COMM_TRANSPARENT == real-transparent Their use is currently good for what they do. A small re-naming is all that is needed there. I'm thinking flags::intercept and flags::realtransparent. Amos -- Please use Squid 2.6.STABLE19 or 3.0.STABLE4
Re: TPROXY support in Squid 3
On Mon, Mar 31, 2008, Alex Rousskov wrote: What about Adrian plans (if I understood them correctly) to add TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a good enough reason to continue supporting unsupported TPROXY versions? The FreeBSD API will be almost like the TPROXY-4 API. I'd suggest supporting TPROXY-2 for a few reasons: * Those who are using it may not want to track the latest kernel + TPROXY patches for various reasons (if it just works; company policy; etc.) and I think its easy enough to maintain support for both without too much hassle. * Supporting both TPROXY-2 and TPROXY-4 will (hopefully!) force someone to integrate it cleanishly and avoid the Squid-2 ip interception mess! * Thus making it easier for me to drop in a FreeBSD version of tproxy without too much hassle (or #ifdef's for that matter.) It shouldn't be that difficult to isolate the bits of the code required for spoofing the client IP in the request versus the TPROXY-specific stuff. In fact, the only tproxy-specific stuff I can really see is: * the logic in forward.c to the local bind, which can be wrapped up as part of the socket creation process, and * The initialisation code, which in the tproxy-2 case does capabilities magic. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
On Tue, Apr 01, 2008, Amos Jeffries wrote: Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch. It'll be sent to trunk soon. The merge It would be a whole lot cleaner and actually less change overall if we could drop the TPROXY version 2 support from Squid-3. I know we will likely need to keep the old support in Squid-2. But with 3.1 we will have the option of saying it requires kernel 2.6.2* or later to run transparent TPROXY. Comments? Abstract out the stuff that you need, and support both. Why? Because FreeBSD will grow the support (I've got the test code here to get ready to commit to FreeBSD) and I don't really want to try and special case a third transparency method. Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
Re: TPROXY support in Squid 3
On Tue, 2008-04-01 at 00:18 +1300, Amos Jeffries wrote: Between Balabit and TreeNet we have come up with a working TPROXY 4+ patch. It'll be sent to trunk soon. The merge It would be a whole lot cleaner and actually less change overall if we could drop the TPROXY version 2 support from Squid-3. I know we will likely need to keep the old support in Squid-2. But with 3.1 we will have the option of saying it requires kernel 2.6.2* or later to run transparent TPROXY. Comments? We may be able to provide better comments when we see the current code. It does not have to be polished and ready for commit. Thank you, Alex.
Re: TPROXY support in Squid 3
tis 2008-04-01 klockan 00:18 +1300 skrev Amos Jeffries: The merge It would be a whole lot cleaner and actually less change overall if we could drop the TPROXY version 2 support from Squid-3. +1 Regards Henrik
Re: TPROXY support in Squid 3
mån 2008-03-31 klockan 08:26 -0600 skrev Alex Rousskov: We may be able to provide better comments when we see the current code. It does not have to be polished and ready for commit. I see no reason to continue supporting now obsolete and no longer supported TPROXY versions in new versions of Squid. Regards Henrik
Re: TPROXY support in Squid 3
On Mon, 2008-03-31 at 20:28 +0200, Henrik Nordstrom wrote: mån 2008-03-31 klockan 08:26 -0600 skrev Alex Rousskov: We may be able to provide better comments when we see the current code. It does not have to be polished and ready for commit. I see no reason to continue supporting now obsolete and no longer supported TPROXY versions in new versions of Squid. What about Adrian plans (if I understood them correctly) to add TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a good enough reason to continue supporting unsupported TPROXY versions? Alex.
Re: TPROXY support in Squid 3
mån 2008-03-31 klockan 13:31 -0600 skrev Alex Rousskov: What about Adrian plans (if I understood them correctly) to add TPROXY-like support to FreeBSD but not for TPROXY4-like API? Is that a good enough reason to continue supporting unsupported TPROXY versions? FreeBSD and TPROXY4 uses pretty much the same API. Earlier TPROXY versions is quite different. Yes, having clean support for multiple APIs is nice, and for Squid-3 we should have TPROXY4 + Adrians FreeBSD thing. If either one want's to spend time on making the older TPROXY support fit in a such framework I won't object strongly, but I see no reason to bother doing so. But yes, it's reasonable to request that TPROXY4 is added using a reasonably pluggable interface in Squid-3 instead of #ifdefs within the code, making way for Adrian to later add the similar FreeBSD glue while keeping the code clean. Regards Henrik
