> 
 > #>Does anyone want a quick introduction to socks?  The www.socks.nec.com
 > #>intro is really bad, full of buzzwords and vagueness. At this moment it
 > #>even appears to be completely inaccessible due to a nice router loop
 > #>provided by psi.net or maybe nec.
 > #>
 > 
 > Yes, please.  I got socks to compile on i386 but it cannot access the 
 > ppp0 device.. claims its not configured.
 > 
 > Tim Rightnour - timr@cii.ciinet.com


Well, it doesn't look like this idea will fly, and a quick intro won't
help at all if you already know enough to be compiling the package.
Anyway, socks doesn't work with the network at low level, if you can't
telnet or ping out the ppp interface from the server, you can't proxy
to it either.

But, FWIW: the socks proxy stuff works by running a daemon (or forking
from inetd) on a bastion host, which may or may not have two actual
NIC's. Client programs on the internal network call Rconnect, which
then reads /etc/socks.conf to see something like:

	direct  your.internal.net.number	255.255.255.0
	sockd  	0.0.0.0 			0.0.0.0

Anything it can get direct it does an ordinary connect() on, but stuff
identified as "sockd" (the outside internet) it must get by opening a
stream on port 1080 of the proxy server, and sending it a message
giving the port and host it really wanted to talk to. The proxy server
("sockd") then opens a real connection to the outside world. It has
a config file (/etc/sockd.conf) that looks like:

	deny   ...internal network
	permit ...the world

It's kind of crude, depends a bit on the order of socket library calls,
and socks4 doesn't work with UDP (although socks5 does). But it is
almost provably secure, and really represents a way to have a nice,
lax, no-security internal network with a vicious firewall that doesn't
require much maintenance or monitoring. There are many newer, much more
sophisticated techniques. But they are a lot more complicated and are
generally expensive.

Netscape has socks support built in to it, although you do have to turn
it on in the proxies submenu.  My idea was to incorporate the socks
proxy logic into the socket library so that all programs would
automatically be socks-capable. It wasn't quite a proposal, just an
idea. Somehow I doubt if people will want to put user-logic around what
used to be a direct system call.

It has been suggested that it should be an optional libc so that if you
don't want it, you don't get it. I can think of lots of good objections
to my idea, but that doesn't seem to be one of them. The whole point of
a socks setup is that /etc/socks.conf directs you to your only possible
choice.  If your machine is socks-isolated, then there would be NO
OTHER WAY to get to a network not identified as direct in
/etc/socks.conf, so there would be no point in not going through the
socks channel.

And if you won't want it at all, don't put in a /etc/socks.conf and it
will do nothing. Certainly you could have a global variable or
init-type function call that would disable it if you like, or a
raw_connect() entry point...

If you are having problems getting it to work: check the following:

	/etc/services:

		socks           1080/tcp

	/etc/inetd.conf:

		socks   stream  tcp     nowait  nobody  /usr/sbin/sockd  sockd
	
server:
	/etc/sockd.conf:
		(system dependent)
	

clients:
	/etc/socks.conf
	

It does all kind of logging. Check syslog!