|
Home Page Back Written: 18-Nov-2000 |
Internet Sharing Solutions (Part 5) By Thiravudh Khoman In Parts 1-3, I covered three different internet sharing solutions: a) the WebRamp, a piece of hardware; b) AnalogX Proxy, a simple Windows program, and c) WinRoute Pro, a much more sophisticated Windows program. In Part 4, I delved deeper into WinRoute Pro, discussing access control issues. In this, Part 5, I'm going to cover the same type of internet sharing methodologies but this time I'm going to use Linux - or more precisely, software that is bundled with most Linux distributions. Again, I recommend reading or at least browsing Parts 1-3 to familiarize yourself with the issues involved. While I intend to go into some detail on the server side, I plan to only skim the client-side setup since we've covered this before.
* * * * * * * * * * IP Masquerding IP Masquerading ("IPM" for short) is probably the most common method of internet sharing available under Linux (one can also use such things as "Socks" servers). As in Parts 1-3, the basics are the same: a central device connects with an ISP, usually via a modem, and acts as a gateway or proxy device for other clients on the network. In this case, the central device is a Linux server. For IPM to work, its capabilities must be compiled into the kernel of the Linux distribution you plan to use (i.e. it can't be loaded afterwards). Fortunately, most newer Linux distributions come with this feature already enabled, so chances are you won't need to do anything in this regard. However, I suggest that you avoid "limited" Linux distributions such as WinLinux, PhatLinux, ZipSlack, etc. since these may be incomplete in certain areas. While it may be possible to add any missing components later, it may be more trouble than it's worth. Stick with the regular distributions. For this article, I'll be using Kaiwal Software's (https://www.kaiwal.com) KW Linux v3.0, a "Thai" Linux distribution derived from Red Hat Linux v6.0. My test environment will again be my home network, consisting of a Celeron-class server that multi-boots between Windows 95 and Linux, while the "client" computers are either Pentium I- or II-class Windows 98 machines. A 5-port hub ties together a simple 10Base-T network. Naturally, all of the client computers have LAN cards. and TCP/IP is "bound" to the LAN cards with fixed IP addresses but with the gateway and DNS servers left blank. An internal 56K modem resides in the Celeron server. Installing Linux Installing Linux isn't very difficult especially if: a) someone has taken you through the process once or twice before, and b) your hardware is Linux-friendly. As I've installed Linux many times previously and made damn sure my hardware was Linux compatible when I built my computer, installation proceeded without a hitch for me. However, because I spend most of my time in Windows, I chose to install Linux in a partition separate from Windows and to multi-boot between the two O/S'es depending on what I wanted to do. I'll skip over most of the Linux installation steps, save for the network setup. Mid-way through the installation, you'll be asked if you'd like to set up LAN (as opposed to dial-up) networking. It's a good idea to do it here and now. My computer has a PCI LAN card that is easily detected as an NE2000 card. What's left is for me to assign an IP address, a host name, a domain name, and optionally, DNS server and gateway addresses. As with the client machines, the Linux server is assigned a fixed IP address (192.168.1.1 in my case), but I left the DNS servers and gateway address blank. A host name and domain must be assigned, but it's not used in our case. Alos, since my Linux server is run on an ad hoc basis, I don't have a local DNS server running either. This is essentially all you need to do with the network stuff except to perform a "ping" test to verify that all of the computers on the network can "see" each other after installation is complete. Dial-Up Configuration After rebooting the Linux server, we proceed to set up the modem, "ppp" (the protocol used to communicate with the ISP), and our ISP settings. This is most easily done under the X Windows System. KDE is the default GUI installed with KW Linux and all of the above can be conveniently configured using "Kppp". After starting X (type: startx), click the "K" button (bottom, left corner), select "Internet" and then "Kppp". Once inside "Kppp", click the "Setup" button and then the "Device" tab. Because my modem is a 56K model set to COM1:, I've set the "Modem Device" field to "/dev/ttys0" (note: COM2 = /dev/ttys1) and the "Connection Speed" field to 115200 (one speed higher than the modem). Next, click the "Modem" tab and then the "Query Modem" button. In a few seconds, a diagnostic dump should be displayed indicating that your modem has been properly detected and set up. If not, then something's wrong. Either the "Modem Device" is wrong (probably a wrong COM port), or whoops, the modem is a Windows or software modem and won't work under Linux. Next, we have to define our ISP settings. Click the "Accounts" tab and then the "New" button. I'm using Samart as my ISP, so under the "Dial" tab, I typed "Samart" in the "Connection Name" field (this is just a label) and one of Samart's access #'s (e.g. 953-7007) in the "Phone #" field. Under the "DNS" tab, I have to specify Samart's DNS servers (unlike with Windows Dial-Up Networking, this has to be entered manually). Samart's DNS servers are: 203.149.0.3 and 203.149.0.2. None of the other tabs need to be fiddled with. Returning to the main "Kppp" screen, I enter my Samart login name into the "Login ID" field and my Samart password into the "Password" field, and then click the "Connect" button. If all goes well, I should be connected to the internet in less than a minute. To test the connection, simply open up a terminal window and type: ping yahoo.com. You should get a response showing the IP address of yahoo.com and a delay time. If not, there's probably a problem with the DNS server settings. Setting Up IP Forwarding So far, we've done nothing that's specific to IPM. We've installed Linux and configured our modem, "ppp", and our ISP settings. This is identical to what a regular would do to access the internet from a standalone Linux machine. Now, for IPM to function, the Linux server must act as a gateway to the internet for the other clients and it has to know how to handle the forwarding of these IP packets. To do this, we need to run a program called "ipchains" (which also happens to be a firewall program) on the Linux server. For some unknown reason, "ipchains" wasn't installed with my KW Linux. Not a problem. The "ipchains" RPM file is available on the program CD and can be installed simply by typing into a console window: rpm -ivh /mnt/cdrom/KWLinux/RPMS/ipchain*.rpm With "ipchains" installed, we must now define a few firewall rules to handle the forwarding of IP packets. "ipchains" can be used to handle some very complex routing and filtering scenarios, but for simplicity's sake we're only going to do the following:
ipchains -A forward -i ppp0 -j MASQ echo 1 > /proc/sys/net/ipv4/ip_forward The last line, of course, is not an "ipchains" command, but simply puts the value "1" into the file "ip_forward", effectively enabling it. Configuring the Clients IPM clients are set up identically to WebRamp clients in Part 1 - you set each client's gateway to the IP address of the Linux server (192.168.1.1) and the DNS servers to the ISP's DNS servers (203.149.0.3 and 203.149.0.2 in Samart's case). For Windows machines, this is done via the Network applet in Control Panel, but clients can be of any persuasion so long as they're running TCP/IP. This setup is different from AnalogX Proxy and WinRoute Pro in non-NAT mode wherein proxy settings have to be defined within a web browser. Personally, I like this method better since I'm now free to use a real caching server to improve speed, such as Samart's proxy.samart.co.th. Putting it All Together
Automating the Process No doubt, you've noticed that I did a lot of things "manually". I ran the "ipchains" commands manually and I connected to the internet manually. Obviously, it's way preferable to do all this automatically or at least to have the required modules loaded "on demand". Alas, I haven't gotten around to doing that yet, but will add it here when I do. Resources This write-up was aided significantly by the following resouces:
|
