LJ Archive CD

Ghosting onto the Net

Scott Steadman

Issue #38, June 1997

Communicating from the office to home using a Linux server and the Internet.

Background

Recently I got the urge to tinker with managing my network at home in order to get some experience with Unix and heterogeneous network management. I have three Windows boxes (two with Windows 95 and one with Windows 3.1) hooked up to a Linux server. I use the LinTel box as both a local file server and as a gateway linking my home network to the Internet.

The software I use to handle the file server tasks is SAMBA. My primary reference for setting up SAMBA was the excellent article on the subject in the July, 1996 issue of Linux Journal.

In picking a dial-up program, I kept two requirements in mind:

  1. I didn't want to manually log on to my ISP each time I wanted access to the Internet.

  2. I didn't want my LinTel box to call up my ISP on startup and then remain connected until I shut it down. I wanted to be considerate of my ISP's other clients by not monopolizing a phone line.

A program written by Eric Schenk, called diald, satisfied both these requirements. I use diald to connect to my ISP whenever I have traffic destined for the Internet. It also automatically disconnects from my ISP if there is no traffic for a specified interval.

I work for various companies with access to the Net, and while at work, I like to access my home Linux server through the Net from time to time—just in case I find something neat during a lunch break that I want to tinker with at home. So I set up my server to connect to the Net at various random intervals between 15 and 60 minutes, loiter around for five minutes and disconnect if there is no traffic. While my server is connected I can download anything I wish. I call this process ghosting.

These are the steps I went through to get ghosting to work. Depending on whether you already have Linux installed and what flavor it is, you may be able to skip some steps.

Linux Installation

The first thing I did was acquire Red Hat 4.0 from Red Hat Software, http://www.redhat.com/. I had heard good things about Red Hat and liked their “Red Hat Package Manager” for handling software bug fixes and upgrades—it sure makes life easier. I installed Red Hat by following the directions given during the install process.

Next, I downloaded the latest version of the kernel available at that time, 2.0.29, from sunsite.unc.edu, and configured my new kernel using hardware specific settings.

Another necessity for ghosting is IP masquerading. I found three good sources of information on IP masquerading:

  1. The most definitive is the IP-Masquerading Resource home page at http://www.wwonline.com/~achau/ipmasq/.

  2. The IP-Masquerading Mini-HOWTO, probably available at your favorite Linux site on the Net.

  3. The last is the IP masquerading article in the July, 1996 Issue of Linux Journal. I downloaded the latest IP masquerading patch for kernel 2.0.28 and higher from the IP-Masquerading Resource home page, and it worked fine with my 2.0.29 kernel. Again, all I had to do was follow the instructions to reconfigure the kernel using the make menuconfig method. Here are the pertinent settings for IP masquerading to work:

  4. Under Code Maturity Level Options, turn on “Prompt for development and/or incomplete code/drivers”. (The IP masquerading code is still considered alpha code.)

  5. Under Networking Options, turn on “Network firewalls”, “Network aliasing”, “TCP/IP networking”, “IP forwarding/gatewaying”, “IP multicasting”, “IP firewalling”, “IP accounting”, “IP masquerading (EXPERIMENTAL)” and “IP tunneling”.

After configuring the rest of the kernel, I just continued following instructions to build it. I recommend doing a make zdisk and making sure the system boots fine from floppy before doing a make zlilo. That way the old kernel doesn't get accidently blown away. My make procedure is:

make dep
make config
make -j5 zdisk
make -j5 modules
make modules_install

I then reboot from the floppy and keep an eye on the startup information. With a successful reboot, go back into the Linux source directory and do a make zlilo. The -j5 switch causes make to spawn up to five compiles simultaneously. This method of compilation speeds up the build process tremendously.

Setting Up the PPP Daemon

After installing Red Hat I set up the point-to-point protocol daemon (pppd); this allows my Linux server to communicate with the Internet. The ppp daemon came with the Red Hat package, and installs automatically when a networking package is selected.

First, I set up a configuration file named /etc/ppp/options, then created a chat script to tell the ppp daemon how to communicate with my ISP. The configuration file I used looks like this:

modem
/dev/cua0
38400
asyncmap 0
defaultroute

The man page for the ppp daemon explains these lines in detail. The default configuration file that comes with Red Hat should suit your purposes. The only line to be concerned about is /dev/cua0—this line tells the ppp daemon where to find your modem.

Before pppd can be used to communicate to the Internet, you have to dial and connect to your ISP. This usually involves a process called handshaking, implemented by a program called chat. A chat script sends the chat program the instructions for logging into your ISP. A chat script is basically a series of wait and send strings. Red Hat provides a network configuration tool that runs under X-Windows and can be used to create and test chat scripts. I had a chat script called /etc/sysconfig/network-scripts/chat-ppp0 (see Listing 1[footnote]). I symbolically linked this script into my /etc/ppp subdirectory using the following commands:

cd /etc/ppp
ln -s /etc/sysconfig/network-scripts/chat-ppp0

You will need to modify my chat script by changing the phone number, username and password responses to match your own. You may also need to modify the line ppp default depending on the requirements of your ISP—contact your ISP for that information.

Listing 1. Chat Script

Now, there are some things I want the system to do right after a successful connect to, or disconnect from, the Internet. Fortunately, pppd has a couple of features that make this easy. When the ppp link comes up, the daemon checks for the existence of a script called /etc/ppp/ip-up. If this script exists, ppp daemon invokes it with the specified connection parameters. My version of this script appears in Listing 2—notice the comments at the top of the script indicate the parameters pppd passes to the script.

Listing 2. /etc/ppp/ip-up Script

When the ppp link goes down, the ppp daemon checks for the existence of a file called /etc/ppp/ip-down. If this file exists, it is invoked when the ppp link is terminated. The contents of my script are shown in Listing 3. This script mainly does some cleanup—undoing what I did in the ip-up script.

Listing 3. /etc/ppp/ip-down Script

Setting up the Dialer Daemon

Next, I acquired and set up the dialer daemon, diald. This handy-dandy piece of software waits until it sees an IP packet destined for the Internet and, if the ppp connection is not up, automatically starts the ppp daemon, which then connects to the Internet.

This package can be obtained from http://www.dna.lth.se/~erics/diald.html. A word of caution—the latest version of diald is 0.16. I am using 0.14. I've tried 0.15, but it had problems reconnecting once I terminated a connection. I have not had time to test out version 0.16. Version 0.14 works just fine for me. If you are interested in upgrading to the latest and greatest diald, send me e-mail, and I'll let you know if it works now. I should have it tested by the time this article is published. Just follow the included instructions to build and install diald.

Listing 4: /etc/ppp/diald-up Script

Once I installed diald, I created some scripts to bring it up and down easily. The script to bring it up is called /etc/ppp/diald-up and appears in Listing 4 with plenty of comments.

Since this script is somewhat obscure, I will cover it in more detail. The route command is used to tell the network software how to get from your computer to other computers and networks. Normally there is a default route the network software uses when it can't find another suitable route in the routing table. To view your routing table, use the netstat -rn command. For more information see the netstat man page.

The first command in Listing 4 removes the default route in order to make sure it is free for diald or the ppp daemon to use. This removal is necessary, since sometimes diald and ppp won't re-assign the default route if one is already assigned.

The second command starts the dialer daemon. (For more details refer to the diald man page.) To use this line in your script, you will need to change three items:

  1. the communications device /dev/cua0

  2. the local address 10.10.10.1

  3. the remote address 192.168.1.2

If you have a fixed IP address, you'll also need to remove the dynamic switch line from the script.

The third, fourth and fifth commands are used to set up the firewall. These commands have to be run after the dialer daemon, because it does the masquerading from the network out to the Internet via the default route. Whenever a packet needs to leave via the default route, the dialer daemon senses it and makes a connection to the Internet using the ppp daemon.

I also have a script to shut down the dialer daemon gracefully. I call it /etc/ppp/diald-down and the source appears in Listing 5.

Listing 5: /etc/ppp/diald-down

The dialer daemon can be communicated with using a named pipe specified on the diald command line in the diald-up script. I use the recommended name /etc/diald.fifo. This named pipe allows you to change various parameters of the program while it is running and to gracefully exit the program without resorting to the kill command.

The first command in Listing 5 tells the dialer daemon to clean up and get out. The second command resets the default route back to the Ethernet card.

Testing the Dialer Daemon

To test the diald script, execute tail -f /var/log/messages in one virtual console, and in another type ping 192.9.9.1 to ping sun.com. After typing the ping command, you can toggle back over to the first console and watch diald spit out status messages. These status messages tell you if diald dials your modem and activates pppd correctly. If ppp appears to connect properly, you can toggle back over to the other console and see if the ping is returned. If not, don't panic—just break out of it using a Ctrl-C and try again. Sometimes packets get dropped when diald is switching the route from the slip interface to the ppp interface.

I used the IP address in the above commands on the assumption that you do not have a name server running on your machine. If you are interested in getting a name server up and running on your machine—something I recommend—a couple of good sources of information are the DNS HOWTO and the Linux Network Administrators Guide by Olaf Kirch.

Create an Appear Script

Next I created an appear script. The appear script causes diald to connect to the Internet, then sends an indication of where the server can be reached to the desired location. I created a script called /etc/ppp/appear to do the work. This script appears in Listing 6.

Listing 6: /etc/ppp/appear Script

Last, I added an entry to the /etc/crontab file. This file is used by the cron daemon to determine what to run when. (For more information on cron take a gander at the cron man page.) This is the line I added:

30 07 * * 1-5 root /etc/ppp/appear

This entry tells the cron daemon to start your appear script Monday through Friday at 7:30 AM. The appear script needs to be started this way only once per day; it will then restart itself whenever the time is right.

After completing all these steps, I was set up to ghost on and off the Internet, and if you've been following these steps, you will be ready too.

A Note about Windows 95 Configuration

If you decide, as I did, to hook up some WinTel boxes to your Linux server, here are some hints to get it up and running.

In the following examples, I am assuming your personal network is on the 192.168.1.* subnet, the Linux server is at 192.168.1.1 and your Win95 machine is at IP address 192.168.1.2.

Select the network icon in your Win95 Control panel. Then select the TCP/IP -> network card entry in the list. Click on properties, so that the properties window will appear, and do the following:

  1. Under the IP Address tab, select “Specify an IP address”, and enter 192.168.1.2 in the IP Address field, also enter 255.255.255.0 in the “Subnet Mask” field.

  2. Under the Gateway tab enter 192.168.1.1 in the “New gateway” field, and click the Add button. This tells Windows that the Linux server is the gateway.

  3. Under the DNS Configuration tab select “Enable DNS”, and enter the host name for your machine in the “Host field”. Then enter the domain you use for your internal network.

  4. If you have the DNS name server running on your Linux server, enter 192.168.1.1 in the “DNS Server Search Order” field and click Add. If you are going to use your ISP's name server, enter your ISP's name server IP address in this field instead.

  5. In the “Domain Suffix Search Order” field, you can re-enter your internal domain and click the Add button.

  6. Last, click on the Okay button. Windows will reboot and you will be set to go.

Conclusion

This setup has worked quite well for me. Every morning before I go to work I decide whether I want to be able to access my box from the office through the Internet. If I do, I just turn it on, and at 7:30 AM cron starts the appear script, and I'm off to the races.

There are some security issues to be aware of—once your server is on the Net, anyone can access it. To prevent people from being able to telnet to your server from anywhere, add the following line to your /etc/hosts.deny file:

ALL: ALL

This entry denies access to your box from everywhere—it is a good default. Now add the following entry to your /etc/hosts.allow file:

ALL: LOCAL myisp.net mywork.com

This entry allows you to connect only from systems on your local network, your ISP and your place of work. (For more information about these files, see the man page for hosts.allow.)

Scott Steadman (ss@stdmn.com) is a contract programmer who lives in Lawrenceville, Georgia with his lovely wife Kim and their two cats.

LJ Archive CD