1RINETD(8) BSD System Manager's Manual RINETD(8)
2
4 rinetd — internet “redirection server”
5
7 /usr/sbin/rinetd
8
10 Version 0.62, 04/14/2003.
11
13 rinetd redirects TCP connections from one IP address and port to another.
14 rinetd is a single-process server which handles any number of connections
15 to the address/port pairs specified in the file /etc/rinetd.conf. Since
16 rinetd runs as a single process using nonblocking I/O, it is able to re‐
17 direct a large number of connections without a severe impact on the
18 machine. This makes it practical to run TCP services on machines inside
19 an IP masquerading firewall. rinetd does not redirect FTP, because FTP
20 requires more than one socket.
21 rinetd is typically launched at boot time, using the following syntax:
23 /usr/sbin/rinetd
25 The configuration file is found in the file /etc/rinetd.conf, unless
27 another file is specified using the -c command line option.
28
30 Most entries in the configuration file are forwarding rules. The format
31 of a forwarding rule is as follows:
32 bindaddress bindport connectaddress connectport
34 For example:
36 206.125.69.81 80 10.1.1.2 80
38 Would redirect all connections to port 80 of the "real" IP address
40 206.125.69.81, which could be a virtual interface, through rinetd to port
41 80 of the address 10.1.1.2, which would typically be a machine on the
42 inside of a firewall which has no direct routing to the outside world.
43 Although responding on individual interfaces rather than on all inter‐
45 faces is one of rinetd's primary features, sometimes it is preferable to
46 respond on all IP addresses that belong to the server. In this situa‐
47 tion, the special IP address 0.0.0.0 can be used. For example:
48 0.0.0.0 23 10.1.1.2 23
50 Would redirect all connections to port 23, for all IP addresses assigned
52 to the server. This is the default behavior for most other programs.
53 Service names can be specified instead of port numbers. On most systems,
55 service names are defined in the file /etc/services.
56 Both IP addresses and hostnames are accepted for bindaddress and connec‐
58 taddress.
59
61 Configuration files can also contain allow and deny rules.
62 Allow rules which appear before the first forwarding rule are applied
64 globally: if at least one global allow rule exists, and the address of a
65 new connection does not satisfy at least one of the global allow rules,
66 that connection is immediately rejected, regardless of any other rules.
67 Allow rules which appear after a specific forwarding rule apply to that
69 forwarding rule only. If at least one allow rule exists for a particular
70 forwarding rule, and the address of a new connection does not satisfy at
71 least one of the allow rules for that forwarding rule, that connection is
72 immediately rejected, regardless of any other rules.
73 Deny rules which appear before the first forwarding rule are applied
75 globally: if the address of a new connection satisfies any of the global
76 allow rules, that connection is immediately rejected, regardless of any
77 other rules.
78 Deny rules which appear after a specific forwarding rule apply to that
80 forwarding rule only. If the address of a new connection satisfies any of
81 the deny rules for that forwarding rule, that connection is immediately
82 rejected, regardless of any other rules.
83 The format of an allow rule is as follows:
85 allow pattern
87 Patterns can contain the following characters: 0, 1, 2, 3, 4, 5, 6, 7, 8,
89 9, . (period), ?, and *. The ? wildcard matches any one character. The *
90 wildcard matches any number of characters, including zero.
91 For example:
93 allow 206.125.69.*
95 This allow rule matches all IP addresses in the 206.125.69 class C
97 domain.
98 Host names are NOT permitted in allow and deny rules. The performance
100 cost of looking up IP addresses to find their corresponding names is pro‐
101 hibitive. Since rinetd is a single process server, all other connections
102 would be forced to pause during the address lookup.
103
105 rinetd is able to produce a log file in either of two formats: tab-delim‐
106 ited and web server-style "common log format."
107 By default, rinetd does not produce a log file. To activate logging, add
109 the following line to the configuration file:
110 logfile log-file-location
112 Example: logfile /var/log/rinetd.log
114 By default, rinetd logs in a simple tab-delimited format containing the
116 following information:
117 Date and time
119 Client address
121 Listening host
123 Listening port
125 Forwarded-to host
127 Forwarded-to port
129 Bytes received from client
131 Bytes sent to client
133 Result message
135 To activate web server-style "common log format" logging, add the follow‐
137 ing line to the configuration file:
138 logcommon
140
142 The -c command line option is used to specify an alternate configuration
143 file.
144 The -h command line option produces a short help message.
146 The -v command line option displays the version number.
148
150 The kill -1 signal (SIGHUP) can be used to cause rinetd to reload its
151 configuration file without interrupting existing connections. Under
152 Linux™ the process id is saved in the file /var/run/rinetd.pid to facili‐
153 tate the kill -HUP. An alternate filename can be provided by using the
154 <code>pidlogfile</code> configuration file option.
155
158 rinetd redirects TCP connections only. There is no support for UDP.
159 rinetd only redirects protocols which use a single TCP socket. This rules
160 out FTP.
161
163 The server redirected to is not able to identify the host the client
164 really came from. This cannot be corrected; however, the log produced by
165 rinetd provides a way to obtain this information. Under Unix, Sockets
166 would theoretically lose data when closed with SO_LINGER turned off, but
167 in Linux this is not the case (kernel source comments support this belief
168 on my part). On non-Linux Unix platforms, alternate code which uses a
169 different trick to work around blocking close() is provided, but this
170 code is untested. The logging is inadequate. The duration of each con‐
171 nection should be logged.
172
174 Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.
175 This software is released for free use under the terms of the GNU Public
176 License, version 2 or higher. NO WARRANTY IS EXPRESSED OR IMPLIED. USE
177 THIS SOFTWARE AT YOUR OWN RISK.
178
180 See http://www.boutell.com/rinetd/ for the latest release. Thomas
181 Boutell can be reached by email: boutell@boutell.com
182
184 Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, the
185 Apache Group, and many others who have contributed advice and/or source
186 code to this and other free software projects.
187LINUX February 18, 1999 LINUX