NAME

     rinetd — internet “redirection server”

SYNOPSIS

     /usr/sbin/rinetd

VERSION

     Version 0.62, 04/14/2003.

DESCRIPTION

     rinetd redirects TCP connections from one IP address and port to another. rinetd is a
     single-process server which handles any number of connections to the address/port pairs
     specified in the file /etc/rinetd.conf.  Since rinetd runs as a single process using
     nonblocking I/O, it is able to redirect a large number of connections without a severe
     impact on the machine. This makes it practical to run TCP services on machines inside an IP
     masquerading firewall. rinetd does not redirect FTP, because FTP requires more than one
     socket.

     rinetd is typically launched at boot time, using the following syntax:

     /usr/sbin/rinetd

     The configuration file is found in the file /etc/rinetd.conf, unless another file is
     specified using the -c command line option.

FORWARDING RULES

     Most entries in the configuration file are forwarding rules. The format of a forwarding rule
     is as follows:

     bindaddress bindport connectaddress connectport

     For example:

     206.125.69.81 80 10.1.1.2 80

     Would redirect all connections to port 80 of the "real" IP address 206.125.69.81, which
     could be a virtual interface, through rinetd to port 80 of the address 10.1.1.2, which would
     typically be a machine on the inside of a firewall which has no direct routing to the
     outside world.

     Although responding on individual interfaces rather than on all interfaces is one of
     rinetd's primary features, sometimes it is preferable to respond on all IP addresses that
     belong to the server.  In this situation, the special IP address 0.0.0.0 can be used. For
     example:

     0.0.0.0 23 10.1.1.2 23

     Would redirect all connections to port 23, for all IP addresses assigned to the server. This
     is the default behavior for most other programs.

     Service names can be specified instead of port numbers. On most systems, service names are
     defined in the file /etc/services.

     Both IP addresses and hostnames are accepted for bindaddress and connectaddress.

ALLOW AND DENY RULES

     Configuration files can also contain allow and deny rules.

     Allow rules which appear before the first forwarding rule are applied globally: if at least
     one global allow rule exists, and the address of a new connection does not satisfy at least
     one of the global allow rules, that connection is immediately rejected, regardless of any
     other rules.

     Allow rules which appear after a specific forwarding rule apply to that forwarding rule
     only. If at least one allow rule exists for a particular forwarding rule, and the address of
     a new connection does not satisfy at least one of the allow rules for that forwarding rule,
     that connection is immediately rejected, regardless of any other rules.

     Deny rules which appear before the first forwarding rule are applied globally: if the
     address of a new connection satisfies any of the global allow rules, that connection is
     immediately rejected, regardless of any other rules.

     Deny rules which appear after a specific forwarding rule apply to that forwarding rule only.
     If the address of a new connection satisfies any of the deny rules for that forwarding rule,
     that connection is immediately rejected, regardless of any other rules.

     The format of an allow rule is as follows:

     allow pattern

     Patterns can contain the following characters: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, . (period), ?,
     and *. The ? wildcard matches any one character. The * wildcard matches any number of
     characters, including zero.

     For example:

     allow 206.125.69.*

     This allow rule matches all IP addresses in the 206.125.69 class C domain.

     Host names are NOT permitted in allow and deny rules. The performance cost of looking up IP
     addresses to find their corresponding names is prohibitive. Since rinetd is a single process
     server, all other connections would be forced to pause during the address lookup.

LOGGING

     rinetd is able to produce a log file in either of two formats: tab-delimited and web server-
     style "common log format."

     By default, rinetd does not produce a log file. To activate logging, add the following line
     to the configuration file:

     logfile log-file-location

     Example: logfile /var/log/rinetd.log

     By default, rinetd logs in a simple tab-delimited format containing the following
     information:

     Date and time

     Client address

     Listening host

     Listening port

     Forwarded-to host

     Forwarded-to port

     Bytes received from client

     Bytes sent to client

     Result message

     To activate web server-style "common log format" logging, add the following line to the
     configuration file:

     logcommon

COMMAND LINE OPTIONS

     The -c command line option is used to specify an alternate configuration file.

     The -f command line option is used to run rinetd in the foreground, without forking to the
     background.

     The -h command line option produces a short help message.

     The -v command line option displays the version number.

REINITIALIZING RINETD

     The kill -1 signal (SIGHUP) can be used to cause rinetd to reload its configuration file
     without interrupting existing connections.  Under Linux™ the process id is saved in the file
     /var/run/rinetd.pid to facilitate the kill -HUP. An alternate filename can be provided by
     using the <code>pidlogfile</code> configuration file option.

LIMITATIONS

     rinetd redirects TCP connections only. There is no support for UDP. rinetd only redirects
     protocols which use a single TCP socket. This rules out FTP.

BUGS

     The server redirected to is not able to identify the host the client really came from. This
     cannot be corrected; however, the log produced by rinetd provides a way to obtain this
     information. Under Unix, Sockets would theoretically lose data when closed with SO_LINGER
     turned off, but in Linux this is not the case (kernel source comments support this belief on
     my part). On non-Linux Unix platforms, alternate code which uses a different trick to work
     around blocking close() is provided, but this code is untested. The logging is inadequate.
     The duration of each connection should be logged.

LICENSE

     Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.  This software is
     released for free use under the terms of the GNU Public License, version 2 or higher. NO
     WARRANTY IS EXPRESSED OR IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK.

CONTACT INFORMATION

     See http://www.boutell.com/rinetd/ for the latest release.  Thomas Boutell can be reached by
     email: boutell@boutell.com

THANKS

     Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, the Apache Group, and many
     others who have contributed advice and/or source code to this and other free software
     projects.