[3800] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: CONFIG_IP_TRANSPARENT_PROXY sample programs?

daemon@ATHENA.MIT.EDU (Nigel Metheringham)
Sun Jul 21 15:39:43 1996

To: Mike Shaver <shaver@neon.ingenia.ca>
cc: david@sealabs.com (David Bonn), linux-net@vger.rutgers.edu
From: Nigel Metheringham <Nigel.Metheringham@theplanet.net>
In-reply-to: Your message of "Wed, 17 Jul 1996 17:22:47 EDT."
             <199607172122.RAA06899@neon.ingenia.com> 
Date: 	Fri, 19 Jul 1996 09:17:54 +0100

[the quotes are getting a bit deep here, so I'll try and summarise 
what David Bonn and myself have previously written]

David thinks that transparent proxies would be a good means to manage 
(kernel level) IP Masquerades.
I said that we then need a Kernel API to the masquerading stuff 
(since fiddling the masquerade tunnels from outside the kernel is 
currently difficult.

Mike Shaver wrote:
} 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

Yes - that'll work - I suggested doing everything in the (user level) 
proxy as an alternative and asked if the kernel API route was worth 
it :-)

The win, although I'm not sure if its a big one, is that using a 
proxy to control masquerade tunnels means that your user level stuff 
is on the complicated but probably low bandwidth (control) 
connection, and your data connections are straight through 
effectively, avoiding the kernel/user/kernel transitions and all 
those buffer copies.  This however could be expanded into an argument 
for putting emacs and Doom into the kernel :-)

} > 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.

Yup, thats my feeling too.
Although proxies controlling masq tunnels appears neat, I think the 
API will be a pain, and for the minor performance gains we might just 
as well do it all in user space, where it probably belongs!

	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  ]




home help back first fref pref prev next nref lref last post