[3738] in linux-net channel archive
Re: CONFIG_IP_TRANSPARENT_PROXY sample programs?
daemon@ATHENA.MIT.EDU (Nigel Metheringham)
Wed Jul 17 16:40:10 1996
To: David Bonn <david@sealabs.com>
cc: Matthias Urlichs <smurf@smurf.noris.de>, linux-net@vger.rutgers.edu,
jos@xos.nl
From: Nigel Metheringham <Nigel.Metheringham@theplanet.net>
In-reply-to: Your message of "Fri, 12 Jul 1996 13:15:17 PDT."
<199607122015.NAA03172@torment.sealabs.com>
Date: Tue, 16 Jul 1996 12:28:36 +0100
[I'm throwing ideas into the ring here rather than suggesting
solutions]
david@sealabs.com said:
} My current thinking is that transparent proxies can be used quite
} efficiently to manage ip masquerading connections. Using a
} transparent proxy for the ftp control connection won't have a
} noticable performance impact, but makes for cleaner, more robust code
} when it comes to building ip masquerading entries for the data
} connection.
I'd agree with this *except* that we then have a user level proxy
(for the ftp control connection) controlling kernel level
masquerading streams (for the data connections). All well and good,
but we need a means of doing this....
So we need some kernel hooks, I guess something like this off-hand:-
- setup masq tunnel (this is the type of connection that shows
up in /proc/net/ip_masquerade rather than the firewall rules
that are normally manipulated).
- other masq tunnel manipulations - tear down, timeouts etc
- do we need information back on when something has happened
to a masqed tunnel - ie when its shut down??
This can be done by reading /proc/net/ip_masquerade
To set a tunnel up we need basically to call ip_masq_new(), passing a
heap of parameters, and need to get back the masqueraded port
numbers.
It ends up feeling rather messy... what would the performance hit be
to do everything in the proxy??
You are having to hoist the data up into user space, copy it and
shove it back down the pipe.... which is a fiar bit more overhead I
guess, can someone with knowlege rather than just opinions comment :-)
[However the checksumming on the masqueraded stuff means that it will
have a heavier processor impact than might be expected. This could
be over come by tweaking the checksums on the basis of what you have
done to the IP header, but I refrained from doing this because it
meant treating data that has passed through a masquerade protocol
helper module (ie ip_masq_ftp.o) differently since you do not know if
the data has been dramatically tampered with within that module.]
So in summary:-
1. If we are going to build composite user level proxy and kernel
level masquerade protocol handlers we need a masquerade kernel
interface.
2. Is this user/kernel split a good idea - would it be stable?
3. The alternative is to do the whole lot in the kernel.
Can you get a transparent proxy like (streamed TCP) interface
within a kernel module?
And another idea...
Has anyone considered the idea of making xinetd (the most recent
version with multiple interface support where you can specify the
listen address for each service), act as a transparent proxy super
server??
Nigel.
--
[ Nigel.Metheringham@theplanet.net - Unix Applications Engineer ]
[ *Views expressed here are personal and not supported by PLAnet* ]
[ PLAnet Online : The White House Tel : +44 113 251 6012 ]
[ Melbourne Street, Leeds LS2 7PS UK. Fax : +44 113 2345656 ]
