8:rinetd
From Linux Man Pages
rinetd - internet ``redirection server
/usr/sbin/rinetd
RINETD(8) BSD System Manager's Manual RINETD(8)
Contents |
VERSION
Version 0.61+syslog+bind, 11/29/2000.
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 [sourceaddress]
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 inter-
face, 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 spe-
cial 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 behav-
ior 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.
The optional sourceaddress can be used to bind to a specific local address for the outgoing connection.
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 connec-
tion 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 deny 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 output in three ways: tab-delimited , web server-style "common log format." both
are file-based or as syslog output.
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
to activate syslog output enter the following line to the configuration file:
syslog facility priority
Example1:
syslog local0 info
in this case all output is logged to the destination configured in your syslogd config for facility local0 and pri-
ority info
Example2:
syslog
in this case everything goes to daemon info
Example3:
syslog wrongfacility wrongpriority
logging to default: daemon info
If configured, the local source address is given in square brackets after the "listening host" entry.
COMMAND LINE OPTIONS
The -c command line option is used to specify an alternate configuration file.
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 Linuxtm 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 theoreti-
cally 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 Logging to syslog added by SuSE. Sourceaddress extension added by Lutz Pressler <lp@SerNet.DE>.
THANKS
Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, the Apache Group, and many others who have con-
tributed advice and/or source code to this and other free software projects.
LINUX February 18, 1999 LINUX