- Transparent Proxy and Redirection with LINUX 2.2
- User-Space Redirection--The Illusion of the Facade
- Transparent Proxy Support--Slight of Hand
- Kernel Port Forwarding--High Wizardry
Transparent Proxy Support—Slight of Hand
This form of redirection augments the kernel with the ability to redirect traffic encountered by the router to a local port. The redirection code is integrated with the firewalling code for input filters. As with any other firewall rules, you have to specify some packet-matching criteria, in addition to the local port to receive these packets. On any router located along the flow of traffic, you can take traffic headed for a particular host or subnet, from a particular subnet—anything that can be specified as an input firewall rule—and redirect it to a local port. A process server capable of dealing with the packet should be running on that port (otherwise the client will get a Connection refused message). This is depicted in Figure 2.
){kind=link}
Kernel redirection using IP transparent proxy.
Instead of a service process, you might have a user-space redirector running on the local port, which then forwards the traffic to some remote system:port, such as transproxy (introduced in the preceding section). If you want to enforce the policy of using proxy servers, you can use transparent proxying to forward all outbound requests for direct connections to the internal proxy server, as shown in Figure 3.
){kind=link}
Kernel plus user-space redirection of traffic.
Strictly speaking, the system doesn't need to be a router, because the firewalling rule must be specified as part of an input rule. In that case, you would redirect traffic from certain sources (the destination will be you, since you're not anybody's gateway) to a particular port, and traffic from other sources to a different port. This is the poor admin's (easy) way to enforce IP-based security (useful for things like inside versus outside) on an ident or finger server by running two separate daemons on different ports, but on the same server.
IP Transparent Proxy Support with the 2.2.x Kernel
The drill for the 2.2 kernel is similar to configuring any of the firewalling rules, and is done with ipchains. Similar to the MASQ target used for masquerading, ipchains allows you to specify REDIR as a target of a rule. You can specify a port, but if you choose not to do so, the kernel will use whatever port was in the original packet's destination field. Before configuring rules, you'll need support in the kernel:
Networking options --->
<*> Packet socket
[*] Network firewalls
[*] TCP/IP networking
[*] IP: advanced router
+ [*] IP: firewalling
+ [*] IP: transparent proxy support (EXPERIMENTAL)
In this example, you want to let everyone know that a server is down, should anyone try to access it. Note that you can use the flexibility of ipchains to redirect traffic from different sources to different destinations.
### redirect all traffic headed for port 80 on moose.mancill.com ### to local port 12970, where a user-space proxy will send the traffic ### to another Web server while moose gets a brain transplant ipchains -A input -p tcp -j REDIR 12970 -s 0.0.0.0/0 -d moose.mancill.com/32 80 ### configure transproxy to listen on port 12970 as user "nobody" ### anything received by the proxy is sent to port 80 ### on cow.mancill.com, which has get-well message about moose ### when people access it with an http://moose... URL tproxy -s 12970 -r nobody cow.mancill.com 80 ### management says that the message is too casual for the external ### customers who use moose, and that it would be better if the ### server were just down with no error message ### (?!? - I'll never understand mgt) # assuming that our internal addresses are 192.168.0.0/16 ipchains -I 1 input -p tcp -j REJECT ! -s 192.168.0.0/16 -d moose.mancill.com/32 80
The above example works well for "onesy-twosy" situations, where there are only a few ports to redirect. However, when the server process is not local to the router, you incur the overhead of user-space redirection. For high-bandwidth applications, it seems like a lot of work to ask the router to review all the packets with firewalling rules and then to copy them into user space to be redirected. Is there a better way? The next section describes a method of establishing the same functionality just discussed, but without using a user-space daemon as described above (namely tproxy).