[2385] in linux-net channel archive
Re: "IP Masquerading for applications"
daemon@ATHENA.MIT.EDU (Mike Shaver)
Sun Apr 7 15:52:56 1996
From: Mike Shaver <shaver@neon.ingenia.com>
To: avalon@coombs.anu.edu.au
Date: Sun, 7 Apr 1996 15:43:21 -0400 (EDT)
Cc: iialan@iifeak.swan.ac.uk (Alan Cox), linux-net@vger.rutgers.edu,
jjciarla@raiz.uncu.edu.ar
In-Reply-To: <199604071707.LAA09163@roxanne.nuclecu.unam.mx> from "Darren Reed" at Apr 8, 96 03:08:44 am
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?
> 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.
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.
Comments?
Mike
--
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <#
#> UNIX medicine man -- dark magick, cheap! <#
#> <#
#> When the going gets tough, the tough give cryptic error messages. <#
#> "We believe in rough consensus and running code." <#
