5.3 The TCP Layer: Ports and Delivery
| only for RuBoard - do not distribute or recompile |
5.3 The TCP Layer: Ports and Delivery
Now that we have fiddled with the routing, the diverted HTTP packets are arriving at the cache's network interface. Usually, an Internet host rejects received packets if the destination address does not match the host's own IP address. For interception caching to work, the cache must accept the diverted packet and give it to the TCP layer for processing.
In this section, we'll discuss how to configure a Unix host for interception caching. If you use a caching appliance, where the vendor supplies both hardware and software, this section may not be of interest to you.
The features necessary to support interception caching on Unix rely heavily on software originally developed for Internet firewalls. In particular, interception caching makes use of the software for packet filtering and, in some cases, network address translation. This software does two important things. First, it tells the kernel to accept a diverted packet and give it to the TCP layer. Second, it gives us the option to change the destination port number. The diverted packets are destined for port 80, but our cache might be listening on a different port. If so, the filtering software changes the port number to that of the cache before giving the packet to the TCP layer.
I'm going to show you three ways to configure interception caching: first with Linux, then with FreeBSD, and finally with the IP Filter package, which runs on numerous Unix flavors. In all the examples, 10.1.2.3 is the IP address of the cache (and the machine that we are configuring). The examples also assume that the cache is running on port 3128, and that an HTTP server, on port 80, is also running on the system.
5.3.1 Linux
Linux has a number of different ways to make interception caching work. Mostly, it depends on your kernel version number. For Linux-2.2 kernels , you'll probably want to use ipchains ; for 2.4 kernels, you'll want to use iptables (a.k.a. Netfilter).
Most likely, the first thing you'll need to do is compile a kernel with certain options enabled. If you don't already know how to build a new kernel, you'll need to go figure that out, and then come back here. A good book to help you with this is Linux in a Nutshell [Siever, Spainhour, Hekman and Figgins, 2000]. Also check out the "Linux Kernel HOWTO" from the Linux Documentation Project at http://www.linuxdoc.org.
5.3.1.1 ipchains
To begin, make sure that your kernel has the necessary options enabled. On most systems, go to the kernel source directory ( /usr/src/linux ) and type:
# make menuconfig
Under Networking options , make sure the following are set:
[*] Network firewalls [*] Unix domain sockets [*] TCP/IP networking [*] IP: firewalling [*] IP: always defragment (required for masquerading) [*] IP: transparent proxy support
Once the kernel has been configured, you need to actually build it, install it, and then reboot your system.
After you have a running kernel with the required options set, you need to familiarize yourself with the ipchains program. ipchains is used to configure IP firewall rules in Linux. Firewall rules can be complicated and unintuitive to many people. If you are not already familiar with ipchains , you should probably locate another reference that describes in detail how to use it.
The Linux IP firewall has four rule sets: input, output, forwarding, and accounting. For interception caching, you need to configure only the input rules. Rules are evaluated in order, so you need to list any special cases first. This example assumes we have an HTTP server on the Linux host, and we don't want to redirect packets destined for that server:
/sbin/ipchains -A input -p tcp -s 0/0 -d 10.1.2.3/32 80 -j ACCEPT /sbin/ipchains -A input -p tcp -s 0/0 -d 0/0 80 -j REDIRECT 3128
The -A input option means we are appending to the set of input rules. The -p tcp option means the rule matches only TCP packets. The -s and -d options specify source and destination IP addresses with optional port numbers . Using 0/0 matches any IP address. The first rule accepts all packets destined for the local HTTP server. The second rule matches all other packets destined for port 80 and redirects them to port 3128 on this system, which is where the cache accepts connections.
Finally, you need to enable routing on your system. The easiest way to do this is with the following command:
echo 1 > /proc/sys/net/ipv4/ip_forward
After you get the ipchains rules figured out, be sure to save them to a script that gets executed every time your machine boots up.
5.3.1.2 iptables
In the Linux-2.4 kernel, iptables has replaced ipchains . Unfortunately, I don't have operational experience with this new software. Setting up iptables is similar to ipchains . You'll probably need to build a new kernel and make sure the iptables features are enabled. According to Daniel Kiracofe's "Transparent Proxy with Squid mini-HOWTO," the only command you need to intercept connections is:
/sbin/iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 80 \ -j REDIRECT --to-port 3128
You'll also need to enable routing, as described previously.
Since iptables is relatively new, the information here may be incomplete. Search for Daniel's mini-HOWTO or see the Squid FAQ (http://www.squid-cache.org/Doc/FAQ/) for further information.
5.3.2 FreeBSD
Configuring FreeBSD for interception caching is very similar to configuring Linux. The examples here are known to work for FreeBSD Versions 3.x and 4.x. These versions have all the necessary software in the kernel source code, although you need to specifically enable it. If you are stuck using an older version (like 2.2.x), you should consider upgrading, or have a look at the IP Filter software described in the following section.
First, you probably need to generate a new kernel with the IP firewall code enabled. If you are unfamiliar with building kernels, read the config(8) manual page. The kernel configuration files can usually be found in /usr/src/sys/i386/conf . Edit your configuration file and make sure these options are enabled:
options IPFIREWALL options IPFIREWALL_FORWARD
Next, configure and compile your new kernel as described in the config(8) manual page. After your new kernel is built, install it and reboot your system.
You need to use the ipfw command to configure the IP firewall rules. The following rules should get you started:
/sbin/ipfw add allow tcp from any to 10.1.2.3 80 in /sbin/ipfw add fwd 127.0.0.1,3128 tcp from any to any 80 in /sbin/ipfw add allow any from any to any
The first rule allows incoming packets destined for the HTTP server on this machine. The second line causes all remaining incoming packets destined for port 80 to be redirected (forwarded, in the ipfw terminology) to our web cache on port 3128. The final rule allows all remaining packets that didn't match one of the first two. The final rule is shown here because FreeBSD denies remaining packets by default.
A better approach is to write additional allow rules just for the services running on your system. Once all the rules and services are working, you can have FreeBSD deny all remaining packets. If you do that, you'll need some special rules so the interception proxy works:
/sbin/ipfw add allow tcp from any 80 to any out /sbin/ipfw add allow tcp from 10.1.2.3 to any 80 out /sbin/ipfw add allow tcp from any 80 to 10.1.2.3 in established /sbin/ipfw add deny any from any to any
The first rule here matches TCP packets for intercepted connections sent from the proxy back to the clients . The second rule matches packets for connections that the proxy opens to origin servers. The third rule matches packets from the origin servers coming back to the proxy. The final rule denies all other packets. Note that this configuration is incomplete. It's likely that you'll need to add additional rules for services such as DNS, NTP, and SSH.
Once you have the firewall rules configured to your liking, be sure to save the commands to a script that is executed when your system boots up.
5.3.3 Other Operating Systems
If you don't use Linux or FreeBSD, you might still be able to use interception caching. The IP Filter package runs on a wide range of Unix systems. According to their home page (http://cheops.anu.edu.au/~avalon/ip-filter.html), IP Filter works with FreeBSD, NetBSD, OpenBSD, BSD/OS, Linux, Irix, SunOS, Solaris, and Solaris-x86.
As with the previous Linux and FreeBSD instructions, IP Filter also requires kernel modifications. Some operating systems support loadable modules, so you might not actually need to build a new kernel. Configuring the kernels of all the different platforms is too complicated to cover here; see the IP Filter documentation regarding your particular system.
Once you have made the necessary kernel modifications, you can write an IP Filter configuration file. This file contains the redirection rules for interception caching:
rdr ed0 10.1.2.3/32 port 80 -> 127.0.0.1 port 80 tcp rdr ed0 0.0.0.0/0 port 80 -> 127.0.0.1 port 3128 tcp
Note that the second field is a network interface name; the name ed0 may not be appropriate for your system.
To install the rules, you must use the ipnat program. Assuming that you saved the rules in a file named /etc/ipnat.rules , you can use this command:
/sbin/ipnat -f /etc/ipnat.rules
The IP Filter package works a little differently than the Linux and FreeBSD firewalls. In particular, the caching application needs to access /dev/nat to determine the proper destination IP address. Thus, your startup script should also make sure the caching application has read permission on the device:
chgrp nobody /dev/ipnat chmod 644 /dev/ipnat
If you are using Squid, you need to tell it to compile in IP Filter support with the --enable-ipf-transparent configure option.
| only for RuBoard - do not distribute or recompile |
