[2386] in linux-net channel archive
Re: "IP Masquerading for applications"
daemon@ATHENA.MIT.EDU (Darren Reed)
Sun Apr 7 16:16:06 1996
From: Darren Reed <avalon@coombs.anu.edu.au>
To: shaver@neon.ingenia.com (Mike Shaver)
Date: Mon, 8 Apr 1996 06:08:54 +1000 (EST)
Cc: avalon@coombs.anu.edu.au, iialan@iifeak.swan.ac.uk,
linux-net@vger.rutgers.edu, jjciarla@raiz.uncu.edu.ar
In-Reply-To: <199604071943.PAA14684@neon.ingenia.com> from "Mike Shaver" at Apr 7, 96 03:43:21 pm
In some mail from Mike Shaver, sie said:
>
> Thus spake Darren Reed:
> > This is an attempt at session or application layer filtering/proxying at
> > the network layer. i.e. it is fundamentally wrong.
>
> But that's true of all transparent proxies, right?
"Transparent" implies can't be seen, although Linux is the only other
I've seen source for, which doesn't imply that it must be done in the
kernel at the network layer.
> > It just doesn't and can't work correctly without recreating the right
> > `stacks' inside the kernel for data reassembly, etc.
>
> What about having one generic ip_masq module which talks to something
> in userland? Presumably, SOCK_PACKET gives you enough control to get
> the ACKs and such correct on the way back to the client. You could
> use the kerneld/arpd-style kernel<->user stuff, or even the netlink
> device, to talk between the kernel and the user layer. You might have
> to stay a few packets "behind" the real data stream, in order to check
> on things like split commands and such, but that shouldn't be too much
> of a problem.
How many packets will be enough ? And you still need to reinvent parts
of the TCP wheel, if not most.
> The other big option is to just add a system call getsockdest() or
> some such which tells you where the socket was originally going, and
> have some additional bind()/listen()/accept() semantics to allow a
> user-level process to intercept forwarded connections. I believe this
> is how the Gauntlet stuff worked. Actually, I recall someone
> mentioning that they had patches to allow transparent proxying. I'll
> see if I can dig this up. I suspect that's a more elegant solution.
Now you're talking :-) This is how I've done it too. Not as speedy but
you create real end-points for TCP and can thus interact with the data
stream better.
darren
