$Header: /CVSROOT/multiproxy/README,v 1.3 2007-05-08 16:19:28 tino Exp $

MultiProxy is a generic single stream proxy implementation.

Compatibility to other protocols like I2P is planned.


How to use:
===========

multiproxy authenticator.sh :1080
socklinger -n -20 :1080 multiproxy authenticator.sh

In the first example it listenes on port 1080 on every interface, in
the second form it serves a single connection from stdin like from
inetd, in the given form it would only serve 20 sessions.  Note that
in the first form it does not "linger" on the socket, so if you need
this (you shouldn't), use socklinger.

authenticator.sh is a script which gets the authentication information
passed on the commandline.  It can be a shell script, C exe program
etc.  It it returns 0 (ok) the access is handled, else it is dropped
by "not allowed by ruleset (2)".

Warning:

This was implemented not for speed but for maximum ease of use just to
get done things quickly in difficult situations.


Supported protocols:
====================

SocksV5
-------

This implementation now is conformant to RFC1928 in that it terminates
the connection after 10 seconds in case of an error if not used from
programs like socklinger.  However if you need lingering (this is,
wait for incoming out outgoing transfer to finish before the program
terminates) you must use socklinger, as it does not wait after the
transfer loop finishes.

This is not compliant to RFC1928 for UDP or bind protocol, as both are
not yet implemented.

Others
------

It's easy to write modules to allow additional Proxy protocols.  All
you need is to be able to autodetect the protocols somehow.


Why?
====

It started because I failed miserably in using socks proxys.  These
use no authentication, RFC931, PAM or whatever.  All this is plain
unusable.

In my environment, all I have is some method how to authenticate the
user, which can be a quite complex task, like looking up a server
database and request some check against crypted password thingies.  So
I need a generic authenticator method.

I failed miserably in compiling other implementations, as needed
libraries are not on my machine or whatever.  However socks is a very
simple thing, so why are other implementations so complex?

As the sourcecode often is quite thrilling I failed miserably in
checking the correctness of other implementations.  The packages
sometimes even have a gigantic size.  And the implementations were
done with an effort, nobody will ever can imagine.  This is quite too
difficult to understand, for me.

So I hacked together my own implementation.  This one is easy to
understand and easy to configure (as there is no configuration at all,
yet).  It even allows to do a manual authenticator where password and
connect requests are interactively authenticated by the user.

-Tino
$Log: README,v $
Revision 1.3  2007-05-08 16:19:28  tino
Document overhauled

Revision 1.2  2007/04/25 15:45:35  tino
Fixed documentation to include current options

Revision 1.1  2006/01/24 07:32:24  tino
First version.  It is working as expected.