This software solves the problem of running a server on a machine whose Internet address is not available to others. The redirection server allows clients to request that the server listen on selected ports on their behalf. Then when someone connects to one of those ports, the redirection server forwards the connection to the client.
Suppose you have a web server running behind a firewall. You can run the redirection server on the firewall machine, and it will forward requests to the web server. You could have multiple web servers running on different machines, and each one could get redirected from a different port on the firewall machine.
Perhaps you have a server running on a machine whose address you would prefer not to advertise. You could use a public redirection server to forward requests from a particular port to your machine. Then you could advertise the address and port of the public redirection server. This way you could avoid receiving spam email or otherwise having your privacy infringed. (This application depends on civic minded souls running public redirection servers. Volunteers can use the guest book on the main page to publish their server addresses.)
The redirection server, redir, runs on Unix or Windows as a command-line program. See below for usage details.
Internet addresses are made up of two parts, an IP address or DNS name, and a port. The IP address is typically described in dotted decimal form, such as 209.1.225.143. A DNS address is expressed as words separated by dots, such as geocities.yahoo.com. Port numbers are generally in the range 1 - 65535, although low numbered ports are privileged on some systems. Most Internet protocols standardize on a particular port number so it is not necessary to specify it explicitly. For example, HTTP defaults to port 80, so if you have a web server running on port 80, your URLs don't have to include it. If it were running on another port such as 1080, then you would have to include ":1080" after the DNS name in your URLs.
The redirection server maintains a database of port numbers that it is listening on, and IP address + port numbers of the remote client that is mapped to each listening port. For example, it could be listening on ports 80, 1080, and 2000, with those mapped respectively to dummy.com:1080, jumble.com:80, and turnip.com:80. When a connection comes in on one of these ports that it is listening to, the redirection server makes an outgoing connection to the corresponding IP address and port number in its database. The server then goes into "transparent" mode, forwarding bytes back and forth between the incoming connection and the remote server.
From the point of view of the client which connected to the redirection server, it is as though it is interacting directly with the remote server, at the IP address and port number of the redirection server. The connected client is not informed about the true IP address that it is talking to; it sees only the address of the redirection server.
The redirection server will maintain multiple connections at one time if necessary. It is even possible for multiple connections to occur on a single port number, each of which produces a separate connection to the same remote server. The data streams are then handled independently.
For additional privacy it is also possible to chain redirection servers together. For example, redirection server A could listen on port 80 and redirect to port 12345 on redirection server B. Server B could redirect connections on port 12345 to port 1080 on end-user server C. Now connections to port 80 on server A get redirected to port 1080 on server C, via server B. This gives server C additional privacy as server A does not see his address. The connect command, described below, is used to set up chains.
In addition to its primary functionality of forwarding incoming connections as described above, the redirection server includes functionality to allow remote machines to modify the database and request that the redirection server listen on specified ports on their behalf.
When the redirection server is started it should be given a command line argument specifying the port for it to listen on. A convention of using port 7154 is suggested. Remote clients can connect to the redirection server on the command port and give commands. An ordinary telnet client is probably the most convenient utility for this purpose.
When initially connected to the redirection server a short banner will be displayed of the form:
Redirection Server Version 0.1
This identifies the version of the redirection server. At this point commands may be given as described below.
Format:
help
The help command lists all of the other commands that are supported by this version of the redirection server.
Format:
listen localport remoteport
Request the redirection server to listen on the specified localport, and to redirect any incoming connections on that port to the specified remoteport on the IP address of the machine which issued the listen command.
Format:
cancel localport
Cancel any existing listen command for the specified localport. The redirection server will stop listening on the port, and remove the corresponding entry from its database.
This command must be given from the same machine which gave the listen command for the localport.
Format:
connect remotehost remoteport
Tells the redirection server to connect to another redirection server running at the specified address. This first redirection server then goes into "transparent" mode and you are then talking to the second redirection server. Any listen commands given to the second redirection server will appear to come from the first redirection server and so the ports will be mapped to connections to the first redirection server. This can be used to set up chains, as described above.
This type of software could be misused for malicious purposes if it were not careful. Several features are included to attempt to prevent such misuse. This should encourage people to run public redirection servers as they are intended to be a positive force for privacy and convenience on the internet.
First, redirections are only done to the IP address from which a request comes. This prevents an attack where a machine is somehow flooded with requests from a redirection server. The only way a machine should see connections is if it requested redirection. (One potential problem occurs when IP addresses are assigned dynamically. An attacker could set up a redirection to his own IP address, then later get the redirection server to send requests to a new user who has been assigned that address. However even in that case it would not be possible for an attacker to target a specific user. If this turns out to be a problem we may have to add some additional precautions.)
Second, the connect command can only be used to connect to another redirection server. It is not an all-purpose IP address connection feature. The first thing that happens is that it looks to see if the remote host is answering with the standard redirection server banner. If not, then the connection does not go through.
Users are encouraged to report in the guest book if they have problems with abuse of the redirection server.