CPSC 441, Networking, Fall 2004
Lab 7: A Private Network

IN THIS LAB, you will convert your server and client machines into a private network. The server will serve as a router and masquerading firewall between the private network and the Internet. The clients will contact the Internet only through the server. This will require some reconfiguration of both the server and the clients.

From the point of view of the server, the private network is also called the internal network, while the campus LAN and Internet play the role of the external network..

Note that while we are setting all this up, the network service to your client machines will be interrupted. Only root will be able to log on, since the clients will not have access to the user info distributed through NFS and NIS (which were set up in Lab 5).

You should complete this lab no later than class time next Friday. You can demonstrate your working network to me at that time. Also at that time, turn in the answers to the four questions given below.

Using Two Ethernet Cards

Your server computer has two Ethernet cards installed, but only one of them is configured. In the first part of the lab, you will activate the second card. One card will be connected to the HWS LAN (and through that to the Internet), and the other card will be connected to your private network.

The private network will be represented by a switch. Currently, all your computers are connected to this switch, and the switch is connected to the HWS LAN. This makes the computers part of the LAN. You need to do the following:

Next, configure the second Ethernet card on the server using Yast. In Yast, click on "Network Devices" on the left, then on "Network Card." In the top part of the "Network card configuration" window, select the unconfigured card, and click the "Configure" button. Another window will open where you can set an IP number and subnet mask. Set it to use "Static Address Setup" with an IP address of 10.0.0.1 and a subnet mask of 255.0.0.0. This is an IP address on the reserved private Class A network, 10.0.0.0/8. Your client machines will have to be assigned IP addresses on this same network. You do not have to change the "Detailed settings"; they are the same for every card and they were already set when the first network card was configured. Just click "Next" and then "Finish".

Use the ifconfig command to see the network configuration. You should have two network interfaces with names eth0 and eth1. Check which interface name goes with each IP address, since you will need this information later. You might also want to check that you still have Internet access, for example with a ping math.hws.edu command.

Question 1: What is the routing table on the server after the two network interfaces are configured? Use the command "route -n" to find out. (The "-n" in this command just says "Don't try to convert IP addresses in the output to domain names".) Report the contents of the routing table and explain what each line means.

Reconfiguring Services on the Server

In Lab 5, you configured the server to run NFS and NIS to share user information with the client machines. NFS was configured so that connections would be accepted only from the client IP addresses. Now, the client IP addresses are going to have to be changed. Reconfigure NFS so that it will accept connections only from IP addresses on the internal 10.0.0.0/8 network. You can configure access for individual client addresses, or you can allow access from any address on the internal network. The latter makes sense if you believe that you have complete control over all the machines on the Internal network (as you do in this case). To allow access by all hosts on the internal network, you only need to use a single rule, using the network number 10.0.0.0/8 to specify the Host.

If you configured NIS to allow access by any host, you do not have to change its configuration. If not, you should make sure that the clients on the Internal network have access.

Setting Up Masquerading

In Linux kernels 2.4 and later, a system called Netfilter is available to provide extensive control over how packets are handled by the TCP/IP system. Netfilter can rewrite and forward packets in very complicated ways. It is configured by a table of "rules". The rule table is manipulated using the iptables command. We will use only a small part of Netfilter's capabilities here. It is used much more extensively behind the scenes by Yast's Firewall configuration tool. In fact, we could set up masquerading using Yast. However, we will do it more directly.

The commands needed to turn on masquerading can be found in the file iptables.sh. You can save this file from a web browser, or you can use scp to copy it from username@cslab1.hws.edu:/classes/f04/cs441/iptables.sh. (If you save it from a web browser, make it executable with the command "chmod +x iptables.sh".

Important note: The iptables.sh script assumes that eth0 is the interface that connects to the campus LAN, while eth1 connects to the internal network. If this is not the case for your setup, edit iptables.sh and reverse the roles of eth0 and eth1.

To start masquerading, run the iptables.sh script on the server. You will not have to do anything special on the clients to make them use masquerading.

This turns on masquerading. You can move on to the client configuration at this point if you want and come back to the rest of this section later. However, masquerading will be turned off when you shut down or reboot the server. In order to make masquerading work after a reboot, you have to make sure that the script is run at boot time. In SuSE Linux, scripts that are meant to be run at boot time are in the directory /etc/init.d. (On other versions of linux, they might be in another directory, such as /sbin/init.d.) Copy the file iptables.sh into this directory, and cd into the directory /etc/init.d. Whether a script is actually run is controlled by entries in the subdirectories rc1.d, rc2.d, rc3.d, and rc5.d. Each of these directories corresponds to a "run level," and different scripts are started for different run levels. Typically, Linux runs at run level 5, which is the GUI login screen. Run level 3 is a console-only log in, but it still has all network services running. (Personally, I always run my servers in run level 3.) The iptables.sh script should be run in run levels 3 and 5. You can add the correct entries to the rc5.d directory by changing to that directory and giving the command

         ln  -s  ../iptables.sh  S07iptables

The "0" after the "S" is a zero. Do the same thing for the rc3.d directory (although it won't affect anything if you leave out this step, unless you convert your server to running in run level 3).

The "ln -s" command sets up a symbolic link to the script file. You could actually place the script itself into the rc directories, but it's traditional to use links to a single script in the /etc/init.d directory. The name must begin with "S" -- which tells Linux to run the script when the system Starts. The "S" must be followed by a number (07) that determines the order in which the scripts are run. The number that you use here must be greater than the network start script, S05network, so that the network is started before the iptables commands are run. (It's actually a little more complicated than this; you might notice that there are also "K" or "Kill" scripts in the rc directories, for example.)

If you've done this correctly, masquerading should be restored at boot time. (During boot time, press the F2 key if you want to see the output from the boot scripts. The output from iptables.sh should be included.)

Reconfiguring The Clients

You will have to reconfigure your client computers to work on the new private network. Do this with Yast:

(In fact, NFS and NIS would probably work using the external server address, but it would require the IP packets to go thorough some extra routing inside the server. Basically, the packets have to be transferred from one interface to the other.)

Check for network access, for example with the command ping math.hws.edu. Check that your NIS and NFS clients are working by logging out and trying to log in as a non-root user. It is possible that Yast might not have correctly restarted all the services. If there is a problem, try re-booting, or ask for help on starting the services by hand.

Question 2: Telnet from a client to math.hws.edu. On math.hws.edu, use the command "last -10" to see information about the last 10 logins. The source IP address or machine name is listed for each login. What IP address is listed as the source of your current login? Explain why.

Question 3: Use ethereal to see what happens to packets as they pass through the server. Start up ethereal. Start a packet capture and in the Packet Capture Window, set the interface to be "any," so that you can see packets from both Ethernet cards. While the packet capture is running, generate some TCP traffic between the client computers and the Internet. Stop the capture. Use a display filter of TCP, and examine the TCP packets that you generated. Describe what you observe, and explain what happened.

Setting Up the Squid Web Proxy

As a final exercise, you will configure the Squid Web Proxy to run on your server. As a web proxy, squid provides a unified web cache that can be used by several computers. As we have seen, such a cache can improve network performance.

You will have to install the squid software package on your server. Use the software installation module of Yast. (Use the Search feature of this module to find the package.)

Squid does not have a nice Yast configuration tool, so you will have to do it the old-fashioned way -- by editing a configuration file by hand. The configuration file is /etc/squid/squid.conf. Edit this file. This is a very large file, but there are only two small changes to make:

            acl  our_networks  src  10.0.0.0/8
            http_access  allow  our_networks

That's it. Save the file. To arrange for squid to be started at boot time, give the command

            insserv  squid

This does not start squid (until reboot). You can start it by hand with the command "rcsquid start". Note that you can stop it with "rcsquid stop", and if you change the configuration file, you can use "rcsquid restart" to load the new configuration. (There are "rc" commands for all the standard services. "rc" stands for "resource control.")

Finally, you have to configure the web browser on the clients to make them use the proxy. (Except, see the note at the bottom.) For Konqueror, use the "Configure Konqueror" command in the "Settings" menu. In the Settings window, click "proxy" on the left. Set the configuration to use "Manually Specified Settings" and click the "Setup" button. Enter 10.0.0.1 for the HTTP server, and use 3128 for the port number.

To check that the proxy is working, access some web pages from the client. On the server, check the file /var/log/squid/access.log. You should see some entries that record the accesses from the client.

Question 4: After setting up the proxy for the Konqueror Web browser on your client machines, access the same static web page, such as http://math.hws.edu/eck/, from both client machines. Look at the squid access log in the file /var/log/squid/access.log. Describe what you see and explain it.

Note about a transparent proxy: The setup described here requires that Web browsers on the client machines be configured to use the proxy server. But the clients can still access the Web directly if they want. An administrator might want to force all Web requests to go through the proxy. This is called a transparent proxy. It looks pretty easy to do, although I haven't tried it myself. You only have to make a few more changes to squid.conf and add one more iptables command. You can get more information and instructions at http://en.tldp.org/HOWTO/TransparentProxy.html. If you do this, you don't have to make any changes on the client machines. Perhaps I will give extra credit, if someone gets a transparent proxy working.