RINETD(8) Unix System Manager's Manual RINETD(8)


NAME

  rinetd -- internet ``redirection server''


SYNOPSIS

  /usr/sbin/rinetd   (on Linux)

  rinetd             (on RISC OS when placed inside your Library)


VERSION

  Version 0.62, 01-Nov-2000


WHERE TO GET

  For Linux:  By  anonymous  FTP  from ftp.boutell.com  in  the  subdirectory
boutell/rinetd as the file rinetd.tar.gz.

  For  Windows  95/98/NT:  By  anonymous  FTP  from  ftp.boutell.com  in  the
subdirectory boutell/rinetd as the file rinetd.zip.

  For RISC OS:  By HTTP from www.sbellon.de and  then following the links  to
the RISC OS software section and subsequently downloading rinetd.zip.


DESCRIPTION

  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  (for Linux)  or
Choices:rinetdrc (for RISC OS).  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 syntax  given  by
SYNOPSIS at the start of this document.

  The configuration file is found in the file /etc/rinetd.conf (for Linux) or
Choices:rinetdrc (for RISC OS), 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   (for  Linux)  or
InetDBase:Services (for RISC OS).

  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

  Examples:

  logfile /var/log/rinetd.log          (for Linux)

  logfile <Wimp$ScrapDir>.rinetd/log   (for RISC OS)

  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

  If you don't want error messages to appear in stderr, but want  them logged
to the log file, add the following to the config file:

  silent

  If you only want non-normal connection messages like "not-allowed", etc. to
appear in the  log file and  not the  normal ones, then  you can specify  the
following in the config file:

  dontlognormal


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   (not
functionally in the RISC OS version). Under Linux(tm) the process id is saved
in the  file /var/run/rinetd.pid  to facilitate the  kill -HUP.  An alternate
file name can be provided by using the pidlogfile configuration file option.


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 the 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  General Public
License, version 2 or higher.

  Changes to it were made by Stefan  Bellon, mainly in order to make it  work
on RISC OS as well as quite some bug fixes and general enhancements.


CONTACT INFORMATION

  See  the rinetd  web page  for the  latest release.  Thomas Boutell  can be
reached by email: boutell@boutell.com

  For questions concerning the RISC OS version, please email Stefan Bellon at
sbellon@sbellon.de as Thomas  Boutell doesn't have any  way to check or  test
the RISC OS version.


THANKS

  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.
