|How to share an Internet|
connection for little or no cost
|- by Ethan Hall Beyer|
In these modern and connected times, a certain issue seems to become a problem more and more often. Many people in the same house or apartment own a computer, and they all want to use the Internet at the same time. The days of cheap, dedicated high speed Internet connections is yet to come, so often the only solution in these cases is to jockey the use of a single modem phone connection. So Internet users in this precarious situation need to figure out how they can all simultaneously Get On The Net. Thankfully, it's not that difficult to do if the computers are already networked in a small home LAN.
Even if the systems aren't networked, some surfers might find the initial investment required to link their computers together well worth it. In this brief tutorial I'll explore how you can set up an computer that is running OS/2 and connected to the Internet, so that other systems connected to the OS/2 machine through a private network, can also access the Internet. And as always, minimal cost for this venture is of interest as well.
The OS/2 server software that allows this "sharing" was made available a few months ago and is now quite mature (despite some bugs, which I am pursuing with the author). This software is a "SOCKS server", and the machines on the private network that need to talk to the Internet, are "SOCKS clients". In a nutshell, here's how it works:
On the clients, the TCP/IP programs know which addresses designate sites on the real Internet, and which ones indicate machines only on the private network. For requests that go to the Internet, the client machine instead sends the request to the SOCKS server which then talks to the real Internet machine, and makes sure that the response it receives is forwarded to the correct client machine. This is done for any type of command that must go to a system on the Internet.
For more technical information on SOCKS, explore the NEC SOCKS site. There is a lot of information here, and setup information for other non-OS/2 systems.
In summary, here are the steps needed to set up a working SOCKS network over an existing LAN:
1. Download, install and configure the SOCKS server (SOCKD.)
2. Download, install and configure the NAME SERVER for the SOCKS server (BIND, DNS Kit, or DNSPROXY.)
3. Test the SOCKS server from a client machine.
4. Configure the computers on the network to talk to the SOCKS server.
5. Automate the startup procedures for the SOCKS server.
So, to get many machines all using a single Internet connection, what do you need to do? First, the computers that will be sharing the connection must be networked together with TCP/IP. This guide isn't a tutorial in setting up a LAN, as there are excellent How-To's on this topic available on the 'net.
Assuming the private network is functioning properly, the required software can now be set up.
1. The actual SOCKS server, properly configured.
2. A Domain Name Server (DNS). For the SOCKS server for OS/2 to function, it requires that a DNS also be running.
Setting up the actual SOCKS server is quite simple. First, obtain the distribution file and unzip it into a separate directory. Though the server can be customized extensively, only a single basic setting is required. This can be set interactively within the server itself once it's running, but I prefer to edit the text configuration files directly.
In your ETC directory, create the file SOCKD.CFG with the single line
permit aa.aa.aa.aa bb.bb.bb.bb 0.0.0.0 0.0.0.0 ge 0where "aa.aa.aa.aa" is your private network address and "bb.bb.bb.bb" is your private network address mask (netmask). For example, see the settings I use.
This file specifies which systems can "talk" through the SOCKS server. In more complicated setups, you could restrict which machines can go to the Internet, and even to which sites on the Internet. Explore the server's help files for more information on these settings.
Once this file is saved, start the server by running SOCKD.EXE. There is no install program, so you might want to create a program object for it.
At this point there still isn't any local DNS running, so the server cannot yet be used.
Setting up the Domain Name Server (DNS)
Having a DNS on the private network is nice. It allows the computers on the network to refer to other systems by name instead of by TCP/IP address, which makes things a lot easier. That aside, the SOCKS server (called SOCKD, or Socket Daemon) for OS/2 requires one, so for our purposes, you will have to set it up.
Surprisingly, it is configuring the name server that is the most complicated part of this whole procedure. There are three main options, and I'll cover how each one is set up.
1. IBM DNS Kit for TCP/IP for OS/2
2. Berkeley Internet Name Daemon (BIND) 4.9.4 OS/2 port
3. DNSPROXY for OS/2
Look here for a information on setting up a basic DNS Kit configuration.
Look here for a information on setting up a basic BIND for OS/2 configuration.
When the DNS is up and running, you should be able to start of the SOCKS server. First, connect to the Internet with OS/2 machine running the server. Then, start up the name server and, finally, update the your configuration "RESOLV" files so that you actually use the local DNS instead of the one appointed by the ISP. Obviously, this tedious procedure should be automated, and I will discuss this at the end of the article.
To test that the server is functioning correctly without further work (you don't need to test this but, if there are problems, it might save some troubleshooting,) you can use WebExplorer or Netscape on one of the machines on the private network to test the server. Configure the browser to Enable a SOCKS server, and enter the IP number of the OS/2 system running the SOCKS server you just set up. If all is well, and the server is connected to the Internet, you should be able to access and view Internet pages from the machine on the private network.
There are four key bits of information needed to SOCKSify any system. Though the actual configuration terms used may vary from system to system, what each system refers to should be clear.
1. SOCKS Domain: This it the domain name chosen for the private network.
2. SOCKS Name Server: Since the OS/2 machine running SOCKD is also running a DNS, this is the numeric IP/machine number of the OS/2 server running the SOCKS program and dialed out to the Internet. pr
3. SOCKS Server: This is identical to the SOCKS Name Server (remember, both DNS and SOCKD are operating together on the OS/2 machine.)
4. Direct Routes: This is a list of network addresses and netmasks that are accessible on the private network, and don't need to be directed to the SOCKS server. In a simple private LAN, this is the private network address and netmask.
NOTE: Make sure you do NOT enable "SOCKS support" in the TCPCFG configuration notebook on the OS/2 machine running the server, unless you know specifically that server machine must communicate through a DIFFERENT socks server, to talk to the Internet. If this is the case, enter the configuration information for that other server, and not circular references to the SOCKS server it is running itself.
Page 1/3 [X] Enable SOCKS SOCKS Userid: (leave blank) SOCKS Domain: (Enter the SOCKS domain name as determined above.) SOCKS Nameserver: (Enter the SOCKS name server as determined above.) Page 2/3 Configure DIRECT Routes. Choose "Add", with these values: Destination IP Address: (Direct route IP as determined above.) MASK: (Direct route mask as determined above) and put in the Destination IP Address and Mask for the direct routes as indicated above. For simple networks there should only be one entry. Page 3/3 Configure Default SOCKS Servers Choose "Add", with these values: SOCKS Server: (The SOCKS Server as determined above.) Destination IP Address: 0.0.0.0 Mask: 0.0.0.0Alternatively (and this is how I prefer doing it), the text SOCKS setup files can be edited or created directly by hand. In the client machine's ETC directory, there are two of these configuration files. Enter the values indicated, without parentheses (see the sample configuration files for an example.)
File SOCKS.ENV: SOCKS_FLAG on SOCKS_DOMAIN (SOCKS Domain) SOCKS_NS (SOCKS Name server) SOCKS_SERVER SOCKS_USER File SOCKS.CFG: direct (private network address) (private network mask) sockd @=(SOCKS server) 0.0.0.0 0.0.0.0
The SOCKS server determines how it forwards requests to the Internet by looking at what TCP/IP connections are active when it starts. Unless you're one of the lucky ones who has a fixed dialup IP number, the server should be restarted after each connection so the new connection values are used. SOCKS can be configured to start the connection automatically when a request for an Internet site is received but, in my experience, there are some slight glitches when this is enabled. (I'm pursuing these with the SOCKD author.)
In addition, connections to the Internet usually imply that whatever Internet dialer is used, updates the server machine configuration files to point to the DNS server operated by the Internet provider. But the SOCKS server is running its own DNS, and should make use of it. So, as well as restarting the SOCKS server after each connection, the DNS configuration files on the SOCKS server must be reset to "point" to the DNS it is running itself. These files are the RESOLV and RESOLV2 files in the ETC directory. They should be identical, and of the form
domain (domain name) nameserver (server IP address)
The "server IP address" can also be the loopback address, if the loopback (127.0.0.1, usually) is defined on the server. Consult the online TCP/IP help for information on this.
In order to automate these tasks, they should be run immediately after a successful connection is established. Some dialers (such as In-Joy or the IBM Advantis dialer) or dial scripts (such as PPPDial) allow you to specify commands to be executed upon connection. If one of these programs is used, it can be configured to perform the required tasks by calling a CMD batch file that performs the required operations. If this CMD file cannot be run automatically, it can be placed in a program object and started manually when needed, after connection. Refer to dialer documentation for information on setting up the "autostart" options.
A sample "autostart" script (STARTSOK.CMD) is provided, though different ones can certainly be used.
There are also limitations to the SOCKS technology that prevent specific Internet applications from functioning. Notable examples are the PING command, and DCC transfers in IRC programs (though otherwise IRC works fine through a SOCKS server). Finally, this whole guide assumes a true LAN, and not one based on direct serial connections. Expanding this setup to include machines directly connected to the SOCKS server via serial cable (much cheaper than Ethernet or Token Ring) may be a topic in an upcoming issue.
By now, hopefully everything is set up and working properly. Feel free to e-mail me if there are questions, and I will answer as time permits. Many thanks to David Head for providing a "test case" in addition to my own private network.
[Our Sponsor: EmTec Innovative Software - OS/2 ISDN, modem and telnet software.]
Copyright © 1996 - Falcon Networking
This page is maintained by Falcon Networking. We welcome your suggestions.
Copyright © 1996 - Falcon Networking