Provided by: rinetd_0.73-1_amd64 bug

NAME

       rinetd - internet redirection server

SYNOPSIS

       rinetd [-f] [-c configuration]
       rinetd -h
       rinetd -v

DESCRIPTION

       rinetd  redirects  TCP or UDP 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 services on machines inside an IP
       masquerading firewall.

       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.

OPTIONS

       -f     Run rinetd in the foreground, without forking to the background.

       -c configuration
              Specify an alternate configuration file.

       -v     Display the version number and exit.

       -h     Produce a short help message and exit.

FORWARDING RULES

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

           bindaddress bindport connectaddress connectport [options...]

       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.

       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.

       Ports default to TCP. To specify the protocol, append /udp or /tcp to the port number:

           206.125.69.81 80/tcp  10.1.1.2 8000/udp

       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, including
       IPv6.

   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 timeout option:

           0.0.0.0 8000/udp  10.1.1.2 80  [timeout=3600]

       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.

   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 src option:

           192.168.1.1 80  10.1.1.127 80  [src=10.1.1.2]

       Assuming  the  local  host  has two IP addresses, 10.1.1.1 and 10.1.1.2, this rule ensures
       that forwarded packets are sent using source address 10.1.1.2.

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 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|deny 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

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  pidlogfile  configuration
       file option.

BUGS AND LIMITATIONS

       rinetd only redirects protocols which use a single TCP or UDP socket. This rules out FTP.

       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.

       Copyright (c) 2003-2021 Sam Hocevar

       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.

CONTACT INFORMATION

       See https://github.com/samhocevar/rinetd/releases for the latest release.

       Thomas Boutell can be reached by email: boutell@boutell.com

       Sam Hocevar can be reached by email: sam@hocevar.net

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.