[3750] in linux-net channel archive
Re: CONFIG_IP_TRANSPARENT_PROXY sample programs?
daemon@ATHENA.MIT.EDU (Mike Shaver)
Thu Jul 18 16:35:27 1996
From: Mike Shaver <shaver@neon.ingenia.ca>
To: david@sealabs.com (David Bonn)
Date: Wed, 17 Jul 1996 17:22:47 -0400 (EDT)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <199607161945.MAA11840@torment.sealabs.com> from "David Bonn" at Jul 16, 96 12:45:03 pm
Thus spake David Bonn:
> >>>>> "Nigel" == Nigel Metheringham <Nigel.Metheringham@theplanet.net>:
> Nigel> david@sealabs.com said:
> Nigel> } My current thinking is that transparent proxies can be used quite
> Nigel> } efficiently to manage ip masquerading connections. Using a
> Nigel> } transparent proxy for the ftp control connection won't have a
> Nigel> } noticable performance impact, but makes for cleaner, more robust code
> Nigel> } when it comes to building ip masquerading entries for the data
> Nigel> } connection.
>
> Nigel> I'd agree with this *except* that we then have a user level proxy
> Nigel> (for the ftp control connection) controlling kernel level
> Nigel> masquerading streams (for the data connections). All well and good,
> Nigel> but we need a means of doing this....
I came in late, so excuse me if I seem confused.[*]
Why don't you just have a means of letting a transparent proxy bind to
an arbitrary address?
Example network:
[client] -------- [proxy box] -------- [real server]
10.1.1.2 10.1.1.1/205.207.219.29 128.214.48.39
The proxy binds to the local port 6666, and the ipfwadm redirect stuff
is set up to correctly forward port 21 `throughbound' connections to
there.
The proxy accepts the connection, then, when it gets a port command:
bind to a port on 205.207.219.29 for the real server to talk to
issue an appropriate port command to the real server
bind to a port on 128.214.48.39
connect to the port on 10.1.1.2 specified by the client
I think this is the traditional means of doing this.
> Nigel> 3. The alternative is to do the whole lot in the kernel.
> Nigel> Can you get a transparent proxy like (streamed TCP) interface
> Nigel> within a kernel module?
>
> This would help a lot, and that gets close to the core problem that
> we're trying to solve. I don't know how possible it is, though.
Given some work, I would think so. You'd have to keep a lot of state,
though, and the kernel might not be the best place for that.
Mike
--
#> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <#
#> Chief System Architect -- will tame sendmail(8) for food <#
#> <#
#> "You are a very perverse individual, and I think I'd like to get to <#
#> know you better." --- eric@reference.com <#
