github-repos/rinetd
1
0
Fork 0
mirror of https://github.com/samhocevar/rinetd.git synced 2025-03-14 20:00:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into feature-ipv6-support

Browse Source
This commit is contained in:
Sam Hocevar 2017-09-11 19:28:53 +02:00
commit 3e18951d7a
18 changed files with 329 additions and 394 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
CHANGES.md
View File

@ -1,3 +1,10 @@
## Version 0.70
* UDP support
* source address binding support
* use a real grammar for the configuration file and get rid of the hand-made
parser
## Version 0.63
* added a `-f` flag to run in the foreground

23
Makefile.am
View File

@ -1,29 +1,14 @@
AUTOMAKE_OPTIONS = foreign dist-bzip2
SUBDIRS = src
EXTRA_DIST = bootstrap CHANGES.md README.md index.html \
parse.peg getopt.c getopt.h $(man_MANS) $(sysconf_DATA)
$(man_MANS) $(sysconf_DATA)
man_MANS = rinetd.8
sysconf_DATA = rinetd.conf
sbin_PROGRAMS = rinetd
rinetd_SOURCES = rinetd.c rinetd.h \
parse.c parse.h \
match.c match.h \
net.c net.h \
types.h
BUILT_SOURCES = parse.c
# If peg/leg is available, regenerate parse.h
parse.c: parse.peg
if which leg >/dev/null 2>&1; then leg -o $@ $^; else touch $@; fi
# _POSIX_C_SOURCE is for SA_RESTART and others
# _XOPEN_SOURCE is for struct sigaction
# _GNU_SOURCE is for h_errno and gethostbyname-related macros
rinetd_CFLAGS = -std=c99 -D_XOPEN_SOURCE -D_GNU_SOURCE -D_POSIX_C_SOURCE=200809L -Wall -Wextra -Wwrite-strings -I.
noinst_DATA = index.html
# This is for Travis CI; we don’t have a testsuite yet.
test:

7
configure.ac
View File

@ -1,9 +1,9 @@
# Process this file with autoconf to produce a configure script.
AC_PREREQ(2.52)
AC_INIT(rinetd, 0.63.test, sam@hocevar.net)
AC_INIT(rinetd, 0.70, sam@hocevar.net)
AC_CONFIG_AUX_DIR(.auto)
AC_CONFIG_SRCDIR([getopt.h])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_SRCDIR([src/rinetd.c])
AC_CONFIG_HEADER([src/config.h])
AM_INIT_AUTOMAKE([no-define tar-ustar silent-rules])
# Checks for programs.
@ -34,4 +34,5 @@ AC_FUNC_STRFTIME
AC_CHECK_FUNCS([gethostbyname memset select socket strstr daemon fork sigaction])
AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([src/Makefile])
AC_OUTPUT

352
index.html
View File

@ -1,232 +1,140 @@
<html>
<head>
<title>RINETD(8)</title>
<style>
body {
background-color: #fffff0;
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<title>rinetd man page</title>
<meta name="generator" content="roffit">
<STYLE type="text/css">
P.level0 {
padding-left: 2em;
}
h3 {
color: #ff8888;
P.level1 {
padding-left: 4em;
}
blockquote,code {
font-family: consolas, monospace, fixed;
font-size: 0.9em;
font-weight: bold;
color: #555555;
P.level2 {
padding-left: 6em;
}
</style>
</head>
<body>
<!--
Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.
This software is released for free use under the terms of
the GNU General Public License, version 2 or higher.
-->
<table>
<tr>
<th width=33% align=left>RINETD(8)
<th width=33% align=right>Unix System Manager's Manual
<th width=33% align=right>RINETD(8)
</tr>
</table>
<h3>NAME</h3>
span.emphasis {
font-style: italic;
}
<p> rinetd -- internet “redirection server”</p>
span.bold {
font-weight: bold;
}
<h3>SYNOPSIS</h3>
span.manpage {
font-weight: bold;
}
<p> <code>/usr/sbin/rinetd</code></p>
h2.nroffsh {
background-color: #e0e0e0;
}
<h3>VERSION</h3>
span.nroffip {
font-weight: bold;
font-size: 120%;
font-family: monospace;
}
<p> Version 0.63, 2017/07/19. Version 0.63 corrects several bugs including a
denial of service security issue, and greatly improves performance, ease of
use, and portability. </p>
p.roffit {
text-align: center;
font-size: 80%;
}
</STYLE>
</head><body>
<h3>WHERE TO GET</h3>
<p> <a href="https://github.com/samhocevar/rinetd/releases">By HTTP on
GitHub</a> in the releases section. </p>
<h3>DESCRIPTION</h3>
<p> 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 <code>/etc/rinetd.conf</code>. 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 <strong>does not redirect FTP</strong>, because FTP requires
more than one socket. </p>
<p> rinetd is typically launched at boot time, using the following syntax: </p>
<blockquote>/usr/sbin/rinetd</blockquote>
<p> The configuration file is found in the file <code>/etc/rinetd.conf</code>,
unless another file is specified using the <code>-c</code> command line option.
</p>
<h3>FORWARDING RULES</h3>
<p> Most entries in the configuration file are forwarding rules. The format of
a forwarding rule is as follows:
<blockquote>bindaddress bindport connectaddress connectport</blockquote>
For example:
<blockquote>206.125.69.81 80 10.1.1.2 80</blockquote>
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. </p>
<p> 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 <code>0.0.0.0</code> can be used. For example:
<blockquote>0.0.0.0 23 10.1.1.2 23</blockquote>
Would redirect all connections to port 23, for all IP addresses assigned to the
server. This is the default behavior for most other programs. </p>
<p> Service names can be specified instead of port numbers. On most systems,
service names are defined in the file /etc/services. </p>
<p> Both IP addresses and hostnames are accepted for bindaddress and
connectaddress. </p>
<h3>ALLOW AND DENY RULES</h3>
<p> Configuration files can also contain allow and deny rules. </p>
<p> 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. </p>
<p> 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. </p>
<p> 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.
</p>
<p> 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. </p>
<p> The format of an allow rule is as follows:
<blockquote>allow pattern</blockquote>
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. </p>
<p> For example: </p>
<p> <blockquote>allow 206.125.69.*</blockquote>
This allow rule matches all IP addresses in the 206.125.69 class C domain. </p>
<p> 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. </p>
<h3>LOGGING</h3>
<p> rinetd is able to produce a log file in either of two formats:
tab-delimited and web server-style “common log format.” </p>
<p> By default, rinetd does not produce a log file. To activate logging, add
the following line to the configuration file:
<blockquote>logfile log-file-location</blockquote>
Example:
<blockquote>logfile /var/log/rinetd.log</blockquote>
By default, rinetd logs in a simple tab-delimited format containing the
following information: </p>
<ul>
<li> Date and time </li>
<li> Client address<br />
<li> Listening host </li>
<li> Listening port </li>
<li> Forwarded-to host </li>
<li> Forwarded-to port </li>
<li> Bytes received from client </li>
<li> Bytes sent to client </li>
<li> Result message </li>
</ul>
<p> To activate web server-style “common log format” logging, add the following
line to the configuration file:
<blockquote>logcommon</blockquote>
</p>
<h3>COMMAND LINE OPTIONS</h3>
<p> The -c command line option is used to specify an alternate configuration
file. </p>
<p> The -f command line option is used to run rinetd in the foreground, without
forking to the background. </p>
<p> The -h command line option produces a short help message. </p>
<p> The -v command line option displays the version number. </p>
<h3>REINITIALIZING RINETD</h3>
<p> The kill -1 signal (SIGHUP) can be used to cause rinetd to reload
its configuration file <strong>without</strong> interrupting existing
connections. Under Linux(tm) the process id is saved in the file
<code>/var/run/rinetd.pid</code> to facilitate the kill -HUP. An alternate file
name can be provided by using the <code>pidlogfile</code> configuration file
option. </p>
<h3>BUGS</h3>
<p> 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 <code>SO_LINGER</code> 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 <code>close()</code> is provided, but this code
is untested. </p>
<p> The logging is inadequate. The duration of the connection should be logged.
</p>
<h3>LICENSE</h3>
<p> Copyright (c) 1997, 1998, 1999,
<a href="http://www.boutell.com/boutell">Thomas Boutell</a> and
<a href="http://www.boutell.com/">Boutell.Com, Inc.</a> </p>
<p> Copyright (c) 2003&mdash;2017 <a href="https://github.com/samhocevar">Sam
Hocevar</a> </p>
<p> This software is released for free use under the terms of the GNU
General Public License, version 2 or higher. </p>
<h3>CONTACT INFORMATION</h3>
<p> See <a href="https://github.com/samhocevar/rinetd/releases">the rinetd web
page</a> for the latest release. </p>
<p> Thomas Boutell can be reached by email: <a
href="mailto:boutell@boutell.com">boutell@boutell.com</a> </p>
<p> Sam Hocevar can be reached by email: <a
href="mailto:sam@hocevar.net">sam@hocevar.net</a> </p>
<h3>THANKS</h3>
<p> Thanks are due to Bill Davidsen, Libor Pechachek, Sascha Ziemann, Joel
S. Noble, the Apache Group, and many others who have contributed advice,
encouragement and/or source code to this and other open software projects. </p>
</body>
</html>
<p class="level0">
<p class="level0"><a name="NAME"></a><h2 class="nroffsh">NAME</h2>
<p class="level0">rinetd - internet redirection server
<p class="level0"><a name="SYNOPSIS"></a><h2 class="nroffsh">SYNOPSIS</h2>
<p class="level0"><span Class="bold">rinetd</span> [<span Class="bold">-f</span>] [<span Class="bold">-c</span> <span Class="emphasis">configuration</span>]
<p class="level0"><span Class="bold">rinetd -h</span>
<p class="level0"><span Class="bold">rinetd -v</span>
<p class="level0"><a name="DESCRIPTION"></a><h2 class="nroffsh">DESCRIPTION</h2>
<p class="level0">
<p class="level0"><span Class="bold">rinetd</span> redirects TCP or UDP connections from one IP address and port to another. <span Class="bold">rinetd</span> is a single-process server which handles any number of connections to the address/port pairs specified in the file <span Class="emphasis">/etc/rinetd.conf</span>. Since <span Class="bold">rinetd</span> 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 services on machines inside an IP masquerading firewall.
<p class="level0"><span Class="bold">rinetd</span> is typically launched at boot time, using the following syntax:
<p class="level0"><span Class="bold"> /usr/sbin/rinetd</span>
<p class="level0">The configuration file is found in the file <span Class="emphasis">/etc/rinetd.conf</span>, unless another file is specified using the <span Class="bold">-c</span> command line option.
<p class="level0"><a name="OPTIONS"></a><h2 class="nroffsh">OPTIONS</h2>
<p class="level0">
<p class="level0"><span Class="bold">-f</span> Run <span Class="bold">rinetd</span> in the foreground, without forking to the background.
<p class="level0"><span Class="bold">-c</span> <span Class="emphasis">configuration</span> Specify an alternate configuration file.
<p class="level0"><span Class="bold">-v</span> Display the version number and exit.
<p class="level0"><span Class="bold">-h</span> Produce a short help message and exit.
<p class="level0"><a name="FORWARDING"></a><h2 class="nroffsh">FORWARDING RULES</h2>
<p class="level0">
<p class="level0">Most entries in the configuration file are forwarding rules. The format of a forwarding rule is as follows:
<p class="level0"><span Class="bold"> bindaddress bindport connectaddress connectport [options...]</span>
<p class="level0">For example:
<p class="level0"><span Class="bold"> 206.125.69.81 80 10.1.1.2 80</span>
<p class="level0">Would redirect all connections to port 80 of the "real" IP address 206.125.69.81, which could be a virtual interface, through <span Class="bold">rinetd</span> 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.
<p class="level0">
<p class="level0">is one of <span Class="bold">rinetd</span>'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:
<p class="level0">
<p class="level0"><span Class="bold"> 0.0.0.0 23 10.1.1.2 23</span>
<p class="level0">Would redirect all connections to port 23, for all IP addresses assigned to the server. This is the default behavior for most other programs.
<p class="level0">Ports default to TCP. To specify the protocol, append <span Class="emphasis">/udp</span> or <span Class="emphasis">/tcp</span> to the port number:
<p class="level0"><span Class="bold"> 206.125.69.81 80/tcp 10.1.1.2 8000/udp</span>
<p class="level0">Service names can be specified instead of port numbers. On most systems, service names are defined in the file <span Class="emphasis">/etc/services</span>.
<p class="level0">Both IP addresses and hostnames are accepted for bindaddress and connectaddress.
<p class="level0">
<p class="level0"><a name="UDP"></a><h2 class="nroffsh">UDP timeout option</h2>
<p class="level0">Since UDP is a connectionless protocol, a timeout is necessary or forwarding connections may accumulate with time and exhaust resources. By default, if no data is sent or received on a UDP connection for 72 seconds, the other connection is closed. This value can be changed using the <span Class="emphasis">timeout</span> option:
<p class="level0"><span Class="bold"> 0.0.0.0 8000/udp 10.1.1.2 80 [timeout=3600]</span>
<p class="level0">This rule will forward all data received on UDP port 8000 to host 10.1.1.2 on TCP port 80, and will close the connection after no data is received on the UDP port for 3600 seconds.
<p class="level0"><a name="Source"></a><h2 class="nroffsh">Source address option</h2>
<p class="level0">A forwarding rule option allows to bind to a specific local address when sending data to the other end. This is done using the <span Class="emphasis">src</span> option:
<p class="level0"><span Class="bold"> 192.168.1.1 80 10.1.1.2 80 [src=192.168.1.2]</span>
<p class="level0">Assuming the local host has two IP addresses, 192.168.1.1 and 192.168.1.2, this rule ensures that forwarded packets are sent using source address 192.168.1.2.
<p class="level0"><a name="ALLOW"></a><h2 class="nroffsh">ALLOW AND DENY RULES</h2>
<p class="level0">Configuration files can also contain allow and deny rules.
<p class="level0">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.
<p class="level0">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.
<p class="level0">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.
<p class="level0">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.
<p class="level0">The format of an allow rule is as follows:
<p class="level0"><span Class="bold"> allow|deny pattern</span>
<p class="level0">Patterns can contain the following characters: <span Class="bold">0</span>, <span Class="bold">1</span>, <span Class="bold">2</span>, <span Class="bold">3</span>, <span Class="bold">4</span>, <span Class="bold">5</span>, <span Class="bold">6</span>, <span Class="bold">7</span>, <span Class="bold">8</span>, <span Class="bold">9</span>, <span Class="bold">.</span> (period), <span Class="bold">?</span>, and <span Class="bold">*</span>. The <span Class="bold">?</span> wildcard matches any one character. The <span Class="bold">*</span> wildcard matches any number of characters, including zero.
<p class="level0">For example:
<p class="level0"><span Class="bold"> allow 206.125.69.*</span>
<p class="level0">This allow rule matches all IP addresses in the 206.125.69 class C domain.
<p class="level0">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 <span Class="bold">rinetd</span> is a single process server, all other connections would be forced to pause during the address lookup.
<p class="level0"><a name="LOGGING"></a><h2 class="nroffsh">LOGGING</h2>
<p class="level0"><span Class="bold">rinetd</span> is able to produce a log file in either of two formats: tab-delimited and web server-style "common log format".
<p class="level0">By default, <span Class="bold">rinetd</span> does not produce a log file. To activate logging, add the following line to the configuration file:
<p class="level0"><span Class="bold"> logfile log-file-location</span>
<p class="level0">Example:
<p class="level0"><span Class="bold"> logfile /var/log/rinetd.log</span>
<p class="level0">By default, <span Class="bold">rinetd</span> logs in a simple tab-delimited format containing the following information:
<p class="level0">&nbsp; Date and time
<p class="level0">&nbsp; Client address
<p class="level0">&nbsp; Listening host
<p class="level0">&nbsp; Listening port
<p class="level0">&nbsp; Forwarded-to host
<p class="level0">&nbsp; Forwarded-to port
<p class="level0">&nbsp; Bytes received from client
<p class="level0">&nbsp; Bytes sent to client
<p class="level0">&nbsp; Result message
<p class="level0">To activate web server-style "common log format" logging, add the following line to the configuration file:
<p class="level0"><span Class="bold"> logcommon</span>
<p class="level0"><a name="REINITIALIZING"></a><h2 class="nroffsh">REINITIALIZING RINETD</h2>
<p class="level0">
<p class="level0">The <span Class="bold">kill -1</span> signal (<span Class="emphasis">SIGHUP</span>) can be used to cause <span Class="bold">rinetd</span> to reload its configuration file without interrupting existing connections.
<p class="level0">Under Linux(tm the process id is saved in the file <span Class="emphasis">/var/run/rinetd.pid</span> to facilitate the <span Class="bold">kill -HUP</span>. An alternate filename can be provided by using the pidlogfile configuration file option.
<p class="level0"><a name="BUGS"></a><h2 class="nroffsh">BUGS AND LIMITATIONS</h2>
<p class="level0">
<p class="level0"><span Class="bold">rinetd</span> only redirects protocols which use a single TCP or UDP socket. This rules out FTP.
<p class="level0">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 <span Class="bold">rinetd</span> 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.
<p class="level0">The logging is inadequate. The duration of each connection should be logged. <a name="LICENSE"></a><h2 class="nroffsh">LICENSE</h2>
<p class="level0">Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.
<p class="level0">Copyright (c) 2003-2017 Sam Hocevar
<p class="level0">This software is released for free use under the terms of the GNU General Public License, version 2 or higher. NO WARRANTY IS EXPRESSED OR IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK. <a name="CONTACT"></a><h2 class="nroffsh">CONTACT INFORMATION</h2>
<p class="level0">See https://github.com/samhocevar/rinetd/releases for the latest release.
<p class="level0">Thomas Boutell can be reached by email: boutell@boutell.com
<p class="level0">Sam Hocevar can be reached by email: sam@hocevar.net <a name="THANKS"></a><h2 class="nroffsh">THANKS</h2>
<p class="level0">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. <p class="roffit">
This HTML page was made with <a href="http://daniel.haxx.se/projects/roffit/">roffit</a>.
</body></html>

324
rinetd.8
View File

@ -1,199 +1,233 @@
.\" 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.
.\"
.Dd July 19, 2017
.Dt RINETD 8
.Os LINUX
.Sh NAME
.Nm rinetd
.Nd internet
.Dq redirection server
.Sh SYNOPSIS
.Nm /usr/sbin/rinetd
.Sh VERSION
Version 0.63, 2017/07/19.
.Sh DESCRIPTION
.Nm 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.
.Pp
rinetd is typically launched at boot time, using the following syntax:
.Pp
/usr/sbin/rinetd
.Pp
The configuration file is found in the file /etc/rinetd.conf, unless
another file is specified using the -c command line option.
.Sh FORWARDING RULES
.TH rinetd 8 "2017-09-09" "rinetd 0.70"
.SH NAME
rinetd \- internet redirection server
.SH SYNOPSIS
\fBrinetd\fR
[\fB\-f\fR]
[\fB\-c\fR \fIconfiguration\fR]
.br
\fBrinetd \-h\fR
.br
\fBrinetd \-v\fR
.SH DESCRIPTION
.PP
\fBrinetd\fR
redirects TCP or UDP connections from one IP address and port to another.
\fBrinetd\fR is a single-process server which handles any number of connections to
the address/port pairs specified in the file \fI/etc/rinetd.conf\fR. Since
\fBrinetd\fR 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 services on machines inside an IP masquerading firewall.
.PP
\fBrinetd\fR is typically launched at boot time, using the following syntax:
.PP
\fB /usr/sbin/rinetd\fR
.PP
The configuration file is found in the file \fI/etc/rinetd.conf\fR, unless
another file is specified using the \fB\-c\fR command line option.
.SH OPTIONS
.TP
\fB\-f\fR
Run \fBrinetd\fR in the foreground, without forking to the background.
.TP
\fB\-c\fR \fIconfiguration\fR
Specify an alternate configuration file.
.TP
\fB\-v\fR
Display the version number and exit.
.TP
\fB\-h\fR
Produce a short help message and exit.
.SH FORWARDING RULES
.PP
Most entries in the configuration file are forwarding rules. The
format of a forwarding rule is as follows:
.Pp
bindaddress bindport connectaddress connectport
.Pp
.PP
\fB bindaddress bindport connectaddress connectport [options...]\fR
.PP
For example:
.Pp
206.125.69.81 80 10.1.1.2 80
.Pp
.PP
\fB 206.125.69.81 80 10.1.1.2 80\fR
.PP
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.
.Pp
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:
.Pp
0.0.0.0 23 10.1.1.2 23
.Pp
206.125.69.81, which could be a virtual interface, through \fBrinetd\fR 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.
.PP Although responding on individual interfaces rather than on all interfaces
is one of \fBrinetd\fR'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:
.PP
\fB 0.0.0.0 23 10.1.1.2 23\fR
.PP
Would redirect all connections to port 23, for all IP addresses
assigned to the server. This is the default behavior for most
other programs.
.Pp
.PP
Ports default to TCP. To specify the protocol, append \fI/udp\fR
or \fI/tcp\fR to the port number:
.PP
\fB 206.125.69.81 80/tcp 10.1.1.2 8000/udp\fR
.PP
Service names can be specified instead of port numbers. On most systems,
service names are defined in the file /etc/services.
.Pp
service names are defined in the file \fI/etc/services\fR.
.PP
Both IP addresses and hostnames are accepted for
bindaddress and connectaddress.
.Pp
.Sh ALLOW AND DENY RULES
.PP
.SS UDP timeout option
Since UDP is a connectionless protocol, a timeout is necessary or forwarding
connections may accumulate with time and exhaust resources. By default, if
no data is sent or received on a UDP connection for 72 seconds, the other
connection is closed. This value can be changed using the \fItimeout\fR option:
.PP
\fB 0.0.0.0 8000/udp 10.1.1.2 80 [timeout=3600]\fR
.PP
This rule will forward all data received on UDP port 8000 to host 10.1.1.2
on TCP port 80, and will close the connection after no data is received on
the UDP port for 3600 seconds.
.SS Source address option
A forwarding rule option allows to bind to a specific local address when
sending data to the other end. This is done using the \fIsrc\fR option:
.PP
\fB 192.168.1.1 80 10.1.1.2 80 [src=192.168.1.2]\fR
.PP
Assuming the local host has two IP addresses, 192.168.1.1 and 192.168.1.2, this
rule ensures that forwarded packets are sent using source address 192.168.1.2.
.SH ALLOW AND DENY RULES
Configuration files can also contain allow and deny rules.
.Pp
.PP
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.
.Pp
.PP
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.
.Pp
.PP
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.
.Pp
.PP
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.
.Pp
.PP
The format of an allow rule is as follows:
.Pp
allow pattern
.Pp
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.
.Pp
.PP
\fB allow|deny pattern\fR
.PP
Patterns can contain the following characters: \fB0\fR, \fB1\fR, \fB2\fR,
\fB3\fR, \fB4\fR, \fB5\fR, \fB6\fR, \fB7\fR, \fB8\fR, \fB9\fR, \fB.\fR
(period), \fB?\fR, and \fB*\fR. The \fB?\fR wildcard matches any one character.
The \fB*\fR wildcard matches any number of characters, including zero.
.PP
For example:
.Pp
allow 206.125.69.*
.Pp
.PP
\fB allow 206.125.69.*\fR
.PP
This allow rule matches all IP addresses in the 206.125.69 class C domain.
.Pp
.PP
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
is prohibitive. Since \fBrinetd\fR is a single process server, all other
connections would be forced to pause during the address lookup.
.Pp
.Sh LOGGING
rinetd is able to produce a log file in either of two formats:
tab-delimited and web server-style "common log format."
.Pp
By default, rinetd does not produce a log file. To activate logging, add
.SH LOGGING
\fBrinetd\fR is able to produce a log file in either of two formats:
tab-delimited and web server-style "common log format".
.PP
By default, \fBrinetd\fR does not produce a log file. To activate logging, add
the following line to the configuration file:
.Pp
logfile log-file-location
.Pp
Example: logfile /var/log/rinetd.log
.Pp
By default, rinetd logs in a simple tab-delimited format containing
.PP
\fB logfile log-file-location\fR
.PP
Example:
.PP
\fB logfile /var/log/rinetd.log\fR
.PP
By default, \fBrinetd\fR logs in a simple tab-delimited format containing
the following information:
.Pp
Date and time
.Pp
Client address
.Pp
Listening host
.Pp
Listening port
.Pp
Forwarded-to host
.Pp
Forwarded-to port
.Pp
Bytes received from client
.Pp
Bytes sent to client
.Pp
Result message
.Pp
.PP
Date and time
.PP
Client address
.PP
Listening host
.PP
Listening port
.PP
Forwarded-to host
.PP
Forwarded-to port
.PP
Bytes received from client
.PP
Bytes sent to client
.PP
Result message
.PP
To activate web server-style "common log format" logging,
add the following line to the configuration file:
.Pp
logcommon
.Sh COMMAND LINE OPTIONS
The -c command line option is used to specify an alternate
configuration file.
.Pp
The -f command line option is used to run rinetd in the
foreground, without forking to the background.
.Pp
The -h command line option produces a short help message.
.Pp
The -v command line option displays the version number.
.Sh REINITIALIZING RINETD
The kill -1 signal (SIGHUP) can be used to cause rinetd
.PP
\fB logcommon\fR
.SH REINITIALIZING RINETD
.PP
The \fBkill -1\fR signal (\fISIGHUP\fR) can be used to cause \fBrinetd\fR
to reload its configuration file without interrupting existing
connections.
.PP
Under Linux\(tm the process id is saved in the file \fI/var/run/rinetd.pid\fR
to facilitate the kill -HUP. An alternate
filename can be provided by using the <code>pidlogfile</code>
configuration file option.
to facilitate the \fBkill -HUP\fR. An alternate filename can be provided by
using the pidlogfile configuration file option.
.Sh 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.
.Sh 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.
.Sh LICENSE
.SH BUGS AND LIMITATIONS
.PP
\fBrinetd\fR only redirects protocols which use a single TCP or UDP
socket. This rules out FTP.
.PP
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 \fBrinetd\fR
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.
.PP
The logging is inadequate. The duration of each connection should be logged.
.SH LICENSE
Copyright (c) 1997, 1998, 1999, Thomas Boutell and Boutell.Com, Inc.
.Pp
.PP
Copyright (c) 2003\-2017 Sam Hocevar
.Pp
.PP
This software is released for free use under the terms of
the GNU Public License, version 2 or higher. NO WARRANTY
the GNU General Public License, version 2 or higher. NO WARRANTY
IS EXPRESSED OR IMPLIED. USE THIS SOFTWARE AT YOUR OWN RISK.
.Sh CONTACT INFORMATION
.SH CONTACT INFORMATION
See https://github.com/samhocevar/rinetd/releases for the latest release.
.Pp
.PP
Thomas Boutell can be reached by email: boutell@boutell.com
.Pp
.PP
Sam Hocevar can be reached by email: sam@hocevar.net
.Sh THANKS
.SH 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.

10
rinetd.conf
View File

@ -15,11 +15,11 @@
# you may specify allow and deny rules after a specific forwarding rule
# to apply to only that forwarding rule
#
# bindadress bindport connectaddress connectport
#127.0.0.1 4000 127.0.0.1 3000
#127.0.0.1 4000/udp 127.0.0.1 22
127.0.0.1 4000 127.0.0.1 3000/udp
127.0.0.1 3000/udp 127.0.0.1 22
# bindadress bindport connectaddress connectport options...
# 0.0.0.0 80 192.168.1.2 80
# 127.0.0.1 4000 127.0.0.1 3000
# 127.0.0.1 4000/udp 127.0.0.1 22 [timeout=1200]
# 127.0.0.1 8000/udp 192.168.1.2 8000/udp [src=192.168.1.2,timeout=1200]
# logging information
logfile /var/log/rinetd.log

0
getopt.c → src/getopt.c
View File

0
getopt.h → src/getopt.h
View File

0
match.c → src/match.c
View File

0
match.h → src/match.h
View File

0
net.c → src/net.c
View File

0
net.h → src/net.h
View File

0
parse.c → src/parse.c
View File

0
parse.h → src/parse.h
View File

0
parse.peg → src/parse.peg
View File

0
rinetd.c → src/rinetd.c
View File

0
rinetd.h → src/rinetd.h
View File

0
types.h → src/types.h
View File