home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / simsockd.zip / sockd.doc < prev    next >
Text File  |  2000-08-13  |  9KB  |  242 lines
  1. A simple SOCKS server for OS/2
  2. ==============================
  3.  
  4. Introduction
  5. ------------
  6. This package contains a very simple SOCKS server for OS/2.  It supports
  7. version 4 of the SOCKS protocol.  This is the version supported directly
  8. by the OS/2 TCP/IP stack, so it is not necessary to use special
  9. 'socksified' clients.
  10.  
  11. You will also need a name server package, since name serving is done using
  12. UDP, and SOCKS version 4 supports TCP only. You can get a small one from:
  13.  
  14.          http://www.tavi.co.uk/os2pages/
  15.  
  16. This SOCKS server contains no security checks; it's just provided as a
  17. lightweight server to permit access to an Internet connection from
  18. multiple clients.  There are other ways of doing this, but this one is
  19. cheap (free!) and consumes few resources. 
  20.  
  21.  
  22. What is SOCKS?
  23. --------------
  24. The SOCKS protocol is described fully elsewhere. Briefly, it is a way of
  25. providing external network access (e.g. to the Internet) via a 'firewall'
  26. machine. This means that there need only be one point of connection to the
  27. Internet, and this can be controlled at will.
  28.  
  29. Essentially, the SOCKS server runs as a process on the system that has
  30. the direct connection (let's assume it is to the Internet); it might
  31. even be a dialup connection.  Any other machine (call it a 'client') is
  32. not permitted direct access to make arbitrary connections outside the
  33. local network.  However, it can ask the SOCKS server to make connections
  34. on its behalf. It can also ask the SOCKS server to 'listen' on ports on
  35. its behalf.
  36.  
  37. The way a client typically works is that any application programs (web
  38. browsers, mail programs, etc.) have to be modified, so that instead of
  39. trying to make connections directly, they do so by connecting to the
  40. SOCKS server and making a special request.  Such modification is often
  41. known as 'socksification'.  For example, Netscape for OS/2 has an option
  42. for using a SOCKS server; you just fill in details of the server and
  43. that's all that is required; connection happens transparently. 
  44.  
  45. However, the story on OS/2 is even rosier.  OS/2 Warp version 4 contains
  46. the facility for automatic 'socksification' of connection requests.  No
  47. modification is necessary; you just create two small configuration files
  48. and all applications are effectively socksified!
  49.  
  50.  
  51. Setting up the server
  52. =====================
  53. Installation and setting up of the server is very easy.
  54.  
  55. Step 1
  56. ------
  57. Copy the program files into place.  Copy SOCKD.EXE to any suitable
  58. directory; it is convenient if this directory is on the PATH.  Also,
  59. copy NETLIB.DLL to a directory that is on the LIBPATH. 
  60.  
  61. Step 2
  62. ------
  63. Locate the ETC directory used by TCP/IP.  If you don't know the location
  64. of this directory, type the command:
  65.  
  66.           SET ETC
  67.  
  68. at an OS/2 command prompt.  You need to edit one file in this directory,
  69. and create another.  We'll call this the ETC directory from now on.
  70.  
  71. Step 3
  72. ------
  73. Edit the file named SERVICES in the ETC directory.  You need to add the
  74. following line, if it isn't there already; it's best to keep the lines
  75. in numerical order (the number in the second column):
  76.  
  77.          socks   1080/tcp
  78.  
  79. Step 4
  80. ------
  81. Create the SOCKD configuration file.  This must be called SOCKD.CNF, and
  82. must reside in the ETC directory. 
  83.  
  84. The format of the configuration file is very simple.  Items within lines
  85. are separated by any number of space or tab characters (as long as there
  86. is at least one).  Anything on a line after (and including) a '#'
  87. character is ignored.  Each line starts with a command, followed by
  88. parameters which depend on the command.  Commands are as below: items in <>
  89. indicate values to be inserted. Commands don't have to be in upper case.
  90.  
  91. PORT    <portnumber>
  92.     This indicates the port on which SOCKD should listen. Normally, this
  93.     command can be omitted, and the default port number derived from
  94.     the SERVICES file (see above) will be used.
  95.  
  96. TRUSTED_INTERFACE   <ipaddress>
  97.     This specifies the IP address (expressed as a dotted quad) of the
  98.     interface on the server that is connected to the local network.
  99.     This interface is taken to be 'trusted', in that only local traffic
  100.     will be handled on it.
  101.     If the server has more than one local interface, this line may be
  102.     repeated in order to specify additional local interfaces.
  103.  
  104. BIND_INTERFACE    <ipaddress/interfacename>
  105.     This specifies the IP address (expressed as a dotted quad) of the
  106.     interface that is connected to the outside world. This is the one
  107.     on which listening will be done, and to which requests will be issued,
  108.     on behalf of SOCKS clients.
  109.     Because, for a dialup connection, the IP address may be assigned
  110.     dynamically, it is permissible to put an interface name here instead
  111.     of the IP address; SOCKD will then obtain the correct associated
  112.     IP address when required. Acceptable interface names are lan0 to lan7,
  113.     ppp0 to ppp3, and sl0 to sl3.
  114.  
  115. A sample SOCKD.CNF is included with the package.  This MUST NOT be used
  116. in its current form; edit to suit your local environment.
  117.  
  118. Step 5
  119. ------
  120. Start the server. The easiest way is to issue the command:
  121.  
  122.     START "SOCKS Server" /MIN /N SOCKD
  123.  
  124. This starts the program minimised, in a VIO window, and it will appear in the
  125. Window List with a meaningful name.
  126.  
  127. To start the server automatically at every boot, add the above command
  128. to the \TCPIP\BIN\TCPEXIT.CMD file.  If that file doesn't exist, create
  129. it, containing just the above line. 
  130.  
  131. Logging
  132. -------
  133. The server maintains a logfile in the ETC directory, under the name
  134. SOCKD.LOG.  This file will grow without bound unless regularly pruned;
  135. its use is really limited to debugging.  It could be deleted or renamed
  136. in TCPEXIT.CMD, just before starting the program. 
  137.  
  138. That's all there is to starting the server.
  139.  
  140.  
  141. Setting up an OS/2 client
  142. =========================
  143. If the client machine is an OS/2 one, then all you have to do is enable
  144. SOCKS support.  You do not need to do anything special in any programs
  145. (e.g.  nominate a SOCKS server).  This is all automatically handled by
  146. OS/2. 
  147.  
  148. Step 1
  149. ------
  150. Locate the ETC directory used by TCP/IP.  If you don't know the location
  151. of this directory, type the command:
  152.  
  153.           SET ETC
  154.  
  155. at an OS/2 command prompt.  You will need to create two files in this
  156. directory.  We'll call this the ETC directory from now on. 
  157.  
  158. Step 2
  159. ------
  160. Create the SOCKS.CFG file in the ETC directory.  Full documentation can
  161. be found in the Assistance Center folder on a Warp 4 system with TCP/IP
  162. installed; open Infornation within that, then Tasks within that, then
  163. TCP/IP Guide within that.
  164.  
  165. Locate the section named "Ensuring Network Security", expand it, and
  166. find the section named "SOCKS Support for TCP/IP Client Applications". 
  167. Select the link "the SOCKS configuration files".  This contains a link
  168. to full documentation on the SOCKS.CFG file. 
  169.  
  170. In summary, all you will probably need are these lines, suitably modified:
  171.  
  172. direct  192.168.1.0       255.255.255.0 
  173. sockd   @=xyz.abc.zzz     0.0.0.0         0.0.0.0
  174.  
  175. The first line specifies a host, or group of hosts, that don't need to
  176. be accessed via SOCKS.  Direct (normal) connection will be used for
  177. these, and this would normally be the case for hosts on your local
  178. network.  Rather than giving individual addresses, you can give a
  179. network address and a mask to be applied to all addresses being checked. 
  180. In the above example, all addresses starting with 192.168.1  would be
  181. treated as direct ones; the 0 in the mask (the second parameter) allows
  182. all values in the last position to match.  This 'direct' line can be
  183. repeated as many times as desired. 
  184.  
  185. The second line specifies how to find a SOCKS server.  All statements
  186. like this must come AFTER the last 'direct' statement.  The name (or IP
  187. address) of the SOCKS server appears first, followed by the IP addresses
  188. (qualified by masks) that the server can reach.  In practice, your SOCKS
  189. server will probably serve for all non-direct addresses, in which case
  190. the line shown will match them all and will be enough.
  191.  
  192. Step 3
  193. ------
  194. Create the SOCKS.ENV file in the ETC directory.  Find documentation in
  195. the same place as for SOCKS.CFG. 
  196.  
  197. A typical SOCKS.ENV file might be:
  198.  
  199. socks_flag      on
  200. socks_user      rde
  201. socks_domain    abc.zzz
  202. socks_ns        192.168.1.11
  203. socks_server    
  204.  
  205. The first line is essential. Have it exactly as shown.
  206.  
  207. The second line gives a username for SOCKS authorisation.  The server
  208. does none, but put the line in anyway, with any string you like as the
  209. parameter!
  210.  
  211. The third line gives the SOCKS domain; use the domain for your local
  212. network. 
  213.  
  214. The fourth line specifies the name server to be used; you'll need to
  215. specify a nameserver on the local network.  A simple one is obtainable
  216. from:
  217.     http://www.tavi.co.uk/os2pages/ 
  218.  
  219. The fifth line is required and should be entered 'as is'.
  220.  
  221. Step 4
  222. ------
  223. That's all. It should work now.
  224.  
  225. History
  226. =======
  227. 1.0    Initial version.
  228. 1.1    Added support for PPP interfaces.
  229. 1.2    Corrected handling of part line comments in config file.
  230.  
  231. Bugs
  232. ====
  233. The server has problems with multiple FTP requests (i.e. via the MPUT and MGET
  234. commands). This is under investigation.
  235.  
  236.  
  237. Bob Eager
  238. rde@tavi.co.uk
  239. August 2000
  240.  
  241.  
  242.